Re: Splice/graft configuration

[Max]
> 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've cobbled something together for cvs2hg, but it requires active
participation by an application-specific subclass of HgOutputOption.
It starts with this template method in HgOutputOption:

  def detect_merge(self, svn_commit, lod, parent1):
    """
    Determine if the CVS commit represented by SVN_COMMIT was a merge in CVS.
    If so, return the Mercurial changeset ID (in binary) of the changeset that
    should be its second parent; otherwise, return None.  The default
    implementation always returns None.

    SVN_COMMIT is a cvs2svn_lib.svn_commit.SVNPrimaryCommit object.

    LOD is an instance of either cvs2svn_lib.symbol.Trunk or
    cvs2svn_lib.symbol.Branch representing the CVS line of development where
    this commit happened.

    PARENT1 is the Mercurial changeset ID (binary) of the first parent.
    """
    return None

(I'm not sure this is the right design: I might want to allow
subclasses to specify both parents.  This sounds weird, but we have
some weird history in our CVS repo that I would like to accurately
reflect in Hg.)

My implementation of detect_merge() is simple:

    def detect_merge(self, svn_commit, lod, parent1):
        return (self._try_automerge_from(svn_commit, lod) or
                self._try_manual_merge(svn_commit, lod) or
                None)

where the _try_automerge_from() and _try_manual_merge() methods are
much more interesting.  The former parses the CVS commit message,
looking for the systematic "MERGE from X: " comments that we have been
using for the last couple of years.  The latter, _try_manual_merge()
is to handle legacy cases -- mainly the merging of old CVS development
branches.

In this case, I chose to identify commits by the tuple (branch,
timestamp, comment_prefix).  I thought about throwing username in
their just to be sure; it wouldn't hurt, but I never got around to it.

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

hg convert's cvs module has a "look for merge messages" feature.

And hg convert in general supports a splicemap, which I gather is
vaguely similar to git's grafts.  It would probably work well
converting from a VC system with sensible revision IDs (svn, git,
...), but it's not too useful converting from CVS.

Greg

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

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