Re: Splice/graft configuration

Max Bowsher wrote:
> Even after (finally) landing yesterday a bunch of changes that I've had
> sitting locally, still have more.
> 
> Namely, support for splicing extra merges into the history. The chief
> sticking point here is a format for configuring the selection of
> revisions. At the moment I'm identifying revisions by their timestamp
> (post fixups) - which works, but is a bit unsatisfying, and I keep
> wondering if I'm going to run into an edge case with 2 revisions with
> the same timestamp.
> 
> Does anyone have any thoughts on how best to write "graft configuration"
> for cvs2*?

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.

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

If this is added to cvs2svn, it could eventually be implemented for all
target VCSs, including even recent versions of SVN.

Michael

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

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