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

Michael Haggerty wrote:
> 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.

Indeed, I first thought that this was my problem. I agree that *this*
problem is tractable.

> 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.)

Not a bad idea, and would actually work fine for my use-case, but only
if it was applied sufficiently late in the passes - I need my symbols to
be able to root themselves in synthetic fixup commits created for other
symbols.

Of course, even better would be if we could come up with a way which
didn't require strict equality, but could feed back generated fixup
changesets into the "best match" logic.

Max.

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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksn4uoACgkQfFNSmcDyxYCLjACgzt0iytKvUSqaDltq3hd92Fge
SqoAn3tvxrR9gPdq4mEtgOgTYKjw1Ul0
=MMnZ
-----END PGP SIGNATURE-----