Re: cvs2git "merge based on commit messages"

On 11/04/2010 10:49 AM, [email protected] wrote:
> thanks for cvs2svn/git.

You're welcome.

> I am looking for a solution to migrate an existing CVS repository to
> git. "git cvsimport" does not work, because of incorrect results.

Yup.  That'll happen.

> One feature I miss in cvs2git comparing to "git cvsimport" is the
> approximative creation of merge-links between branches based on
> commit messages (like "merged from RELEASE_1_2").

I'm not familiar with that feature, but it sounds like fun.  How does it
work in "git cvsimport"?

> Do you know if anyone has tried such a thing with cvs2git? Could you
> give me hints, how to implement it in the cvs2git code?

I can't think of anybody having done this before.  (Maybe ossi did
something like this for the KDE conversion?)

It's not going to be trivial to figure out what revision of the source
branch to consider to be merged to the destination.

The easiest thing would be to just use the most recent revision from the
source branch as the second merge parent, and cross your fingers that
(1) people didn't merge from an older revision and (2) the timestamps
are accurate.

When using CVS it is recommended to place a tag on the revision that is
being merged from.  If such tags are present it would be nice to make
use of them.

cvs2git generates its output in chronological order, so if you always
want to use the latest revision of the merged-from branch, you would
have to remember the git-fast-import mark at the tip of every branch and
reference that in the merged-to revision.  I think that the
GitOutputOption class has enough information to do this, so the changes
could be very isolated to the git output code.

Of course it would be even nicer if this functionality were implemented
earlier in the conversion, where other backends could take advantage of
it.  (Even Subversion records merge info nowadays!)  The implementation
depends strongly on how flexible the merge parent determination is made:

1. Only source branch; just take the latest revision on that branch--in
this case, the merge source (branch) could be recorded in the SVNCommit
instance near the end of the conversion or even in the Metadata when the
log message is first processed.

2. Merge from specific tag--the merge source would probably have to be
recorded file-by-file, perhaps in the CVSRevision instances.  In this
case there could be a lot of complications, for example if the tag
doesn't appear in all files or if the creation of the tag has to be
split up among multiple commits.

Either way the information could be used by any backend, but on the
other hand the other backends could just ignore the information
unless/until they know how to deal with it.

Another, git-specific possibility would be to do the whole thing
post-conversion using git tools.  One would only have to create a git
"grafts" file listing each merge commit with its two parent SHA1s, then
use "git filter-branch" to make the grafts permanent.  All this should
be done, of course, before publishing the git repository.

Let me know if you have any more questions.

Michael

-- 
Michael Haggerty
[email protected]
http://softwareswirl.blogspot.com/

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

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