Re: A flaw in finding minimal-complexity symbol conversions?

Max Bowsher wrote:
> I've been staring at a CVS repository I need to convert and one thing I
> note is that there are often cases where a branch and a tag sprout from
> the same point and need exactly the same fixup changes.
> 
> After pondering this for a while, I'm mostly convinced that implementing
> this is more trouble than it's worth, because you'd have to do something
> along the lines of feeding back synthetic changesets into the
> opening/closings logic, at which point my head starts to explode.
> 
> But I just thought I'd bring up the topic, and see if anyone had some
> interesting insight.

One obvious deficiency in the parent-choosing code is that it does not
consider file deletions.  In other words, cvs2svn does not distinguish
between a potential parent that is identical to the new symbol and one
along the same LOD that has an *extra* file compared to the symbol.  If
your fixups mainly involve file deletions, this may be your culprit.  I
think that fixing this problem is tractable, though nontrivial.

Vendor branches are also not considered as possible parents even when
the vendor branch contents are identical to those on trunk.

I have wondered whether it would be possible to eliminate trivial
duplicates using some kind of content hash comparison.  Effectively, git
does this automatically because of its content-addressed filesystem; two
commits that "coincidentally" have the same contents get the same SHA1
and so *are* one and the same (modulo a "git gc").  Perhaps cvs2svn
could do something similar when choosing parents.  (Obviously, the
revision contents would not have to be hashed; it would be enough to
hash a proxy, like the set of ids of CVS file revisions that make up the
commit.)

Michael

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=2430436

To unsubscribe from this discussion, e-mail: [[email protected]].