Proving ownership of code with mercurial?

[Peter Arrenbrecht]

On Jan 2, 2008 10:44 AM, Francesc Esplugas <francesc.esplugas at gmail.com> wrote:
>
> I've been working on a project during three months and as I work
> freelance they say I only worked the first 6 weeks. Everything is
> under Mercurial with daily changesets (and these changesets contain
> data). The repo distributed in a few machines, but I keep the master.
>
> I know all the work that I've made, and I've printed the list of
> changesets, so I can explain my client all the work, but they might
> say I've changed the repos to reflect this "log history".

Tough. As I said, it's easy to fabricate backdated logs (as an
example, consider the convert extension). So for the repo's log to
help you, you need copies of the repo that are *provably* as old as
the changesets whose dates you wish to establish. For example, trusted
dated backups of the repo your employer - or preferably some third
party - has on file.

But, as I already hinted, doesn't the playing out of the actual
changes in the repo demonstrate that it contains 3 months' worth of
actual work, meaning lines written, lines changed, etc., disregarding
any dates in the log? Of course this hinges on an estimate of your
productivity and on stuff like time it took to think etc. But still,
if you're lucky, replaying the changes should, for each day, show work
that roughly takes a day to do. It's much harder to fake that.

> The question should be ... should I trust the repos? In a Git
> conference Linus Torvals talked about the security of Git, about
> trust. He can know if someone has hacked the repository ... bla bla
> bla ... so the idea would be to show to my client, that the repos
> hasn't changed and that he can trust it ...

He can know if a repo he sees was hacked versus some copy (or just a
hash) *he*trusts*. (More precisely he knows whether the history in the
repo prior to said hash was hacked.) He cannot trust any part of a
repo of which he's never seen and trusted (for whatever reason) any
copies before.

So this is the point raised before: it's a social problem. You need to
base your trust somewhere.

-peter


> On Jan 2, 2008, at 10:32 AM, Peter Arrenbrecht wrote:
>
> > On Jan 2, 2008 9:34 AM, Dustin Sallings <dustin at spy.net> wrote:
> >>
> >> On Jan 1, 2008, at 23:59, Francesc Esplugas wrote:
> >>
> >>> I want to prove all the work I've done. I understand some of my code
> >>> can be a copy and paste from other projects or other developers, but
> >>> the idea is to prove I've been working on the project.
> >>>
> >>> Proving the integrity (hg verify) of the repository, could prove
> >>> nobody hacked it?
> >>
> >>
> >>        If you can update to a version whose ancestry includes your
> >> changes,
> >> then those changes are there.  Anyone who's cloned the tree would
> >> notice if you tried to rewrite history somewhere and pass it off as
> >> their upstream.
> >>
> >>        Sounds like you might be fighting an uphill battle, though.
> >> Good luck.
> >
> > Key point: If no one ever cloned your repo, then the repo's integrity
> > won't help you. It is easy to create a brand new repo with backdated
> > history. And if the repo contains only your changes (not interleaved
> > with changes by others), you would need the other party to have
> > demonstrably old clones which show your changes really are as old as
> > you claim.
> >
> > But, as someone noted before, this is about who has to prove what. So:
> > what exactly do you want to prove? Time spent? Goals achieved? Lines
> > of code contributed? What?
> >
> > And why do you feel you need to prove this? If they claim you
> > reattributed changes done by others to yourself, where are those
> > others? What grounds have they for making the claim? If they claim the
> > result is not worth 3 months' time, then the repo should show the
> > evolution of the result, which might show otherwise. But this does not
> > hinge on the repo's integrity.
> >
> > -peter
>
>
> --
> name. Francesc Esplugas i Martí
> voice. +34 678.681.603
>
>