Re: Splice/graft configuration

Michael Haggerty wrote:
> I was happy a while back to discover that git has support for a "grafts"
> file that allows the apparent parentage of historical revisions to be
> faked.  It is also very easy to use "git filter-branch" to rewrite the
> git repository to incorporate the parentage changes permanently (though
> of course this changes the SHA1s of all subsequent commits).  So for
> cvs2git, the simplest approach is probably to use git's facility
> post-conversion rather than trying to invent a new "graft configuration"
> for cvs2svn.
> 
> On the other hand, the grafts file cannot be written until the final
> cvs2git conversion is done, because before then the SHA1s are not
> predictable (even those from a test conversion might not be consistent
> with those from the final conversion).  And yet the repository cannot be
> published until the post-grafts rewrite is done because only then are
> the *final* SHA1s determined.
> 
> Presumably bzr and hg do not have such a facility.  I would almost
> suggest adding the "grafts" facility to the target VCS rather than
> adding it to cvs2svn.  This would allow the user to use the VCS's
> standard visualization tools to help figure out which commits should be
> treated as merges, and the feature might be useful in other contexts
> unrelated to cvs2xxx.

You'd still need to rewrite all of history to "fixate" any changes, at
which point, rerunning the cvs2xxx conversion to "fixate" your synthetic
merges isn't implausible.

> But if you want to implement this in cvs2xxx, then another possibility
> would be to denote the changeset that should be a merge by simply
> listing a single file revision that you know will be in the changeset,
> like "src/path/file.c:1.5.6.4".  cvs2svn could figure out which
> changeset this corresponds to.  Even though this would not be completely
> general, it would probably be easier for the user to deal with than
> timestamps that are not even generated until late in the cvs2svn
> conversion (and not guaranteed to be consistent from one run to the next).

I have to admit that I hacked things up using timestamps because I could
easily copy/paste them out of bzr's visual log viewer :-)

That said, I have to agree that your idea is a very neat one. With some
additional syntax to support selecting symbol creation commits, it
should work out nicely.


Max.

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

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

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

iEYEARECAAYFAkr4ulcACgkQfFNSmcDyxYAHtQCeK86raCxi0+1vLSObZFIVlvRS
wP0An1tGhWURFW4YIOz/5B0yhXCMjBv5
=hthW
-----END PGP SIGNATURE-----