Finding a fork point
Nicolas Dumazet
nicdumz at gmail.com
Mon Jul 5 02:02:30 UTC 2010
2010/7/2 Paul Sargent <psarge at gmail.com>:
> The only problem is that the results have probably confused me even
> more. Some revisions have low numbers of files changed, some have low
> insertions, and some have low deletetions. The insertions and
> deletions minima seem to be on different branches, so something rather
> odd is going on.
That might simply mean that the "fork" point was not only a single
cset on one branch.
It's very much possible that the fork took bits of branch A, bits of
branch B, other bits of C but pruning csets x1, x2 and x3, etc...
As long as they did not want to keep history, there is no problem in
doing this, and it will be extremely hard to find the "correct" set of
multiple sources. Actually, if you are a bit old-fashioned it might
make sense to take, for example, the best version of each file from
all "interesting" branches, and merge everything manually. Finding any
information of interest from the result of such surgery sounds...
difficult.
Maybe writing down checksum matches might help, as Daniel suggested.
The idea would be:
for each file in the resulting fork, find the latest cset (if
any) that has an identical checksum.
That *could* help narrowing down/coloring the branches that were used,
but of course as long as a minor change is introduced, you lose the
checksum match: so if the company changed all headers for example,
that would not give any information.
>
> More investigation required.
>
> Paul
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
--
Nicolas Dumazet — NicDumZ
More information about the Mercurial
mailing list