Re: Fixing cvs2svn branchpoints

["Eric S. Raymond" <esr@thyrsus.com>]

Joseph Myers <joseph@codesourcery.com>:
> Which mid-branch deletes?  For the ones by accident (e.g. the deletions of 
> trunk), where the branch was recreated by copying from the pre-deletion 
> version of the same branch, nuking the deletes is clearly right.  For the 
> ones where a branch was deleted then recreated as a copy not from the 
> deleted version - essentially, rebasing done in SVN - maybe we need 
> community discussion of the right approach.  (There are two plausible 
> approaches there - either just discard all the deleted versions that 
> aren't part of the SVN history of the most recent creation of the branch, 
> which makes the list of commits in the branch's history in git look 
> similar to what it looks like in SVN, or treat deletion + recreation in 
> that case as some kind of merge.)

To get content right, reposurgeon has to run through all nodes looking for
branches with more than one creation.  For each such clique, it has to change
all instances but the last so that the branch has a unique nonce name,
then run forward and patch all copy references to the each branch to use
the nonce name.

Only the last branch in each clique will be visible (and not renamed)
in the git conversion.  But the earlier branches can't simply be
nuked, as they might be (and typically are) referenced by branch
copies done before the final branch in the clique was created.

This might sound like it will get the special case of a trunk
delete/recreate wrong.  But when git imports a stream it does its own 
branch recoloring based on tip resets and parent-child-relationships; 
we can expect trunk to be (effectively) re-colored back to the root commit.

(This whole mess around branch re-creation is something other
conversion tools don't even try to get right.)

The other case - where you delete a target branch and copy a different
source branch over it - is simpler.  Because branch names in the
git conversion are controlled by the SVN repository pathname (root becomes
master, branches/foo becomes branch foo, etc), this looks exactly like
an ordinary modification of the target branch.

Presently, the fact of the copy is not recorded in the DAG. I could express 
it as a git merge link; that wouldn't be difficult.

> > Also please open reposurgeon issues about the svnmerge properties
> 
> As I understand it, support for that has now been implemented.

It has, yes.

> > and the missing documentation.
> 
> https://gitlab.com/esr/reposurgeon/issues/151 filed - it's a lot more than 
> just reparent for which documentation appears to have disappeared.

A large chunk of the section on surgical comands vanished, probably
due to a finger error wgile I was editing the translation.  I have
restored it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>