Joseph Myers <jos...@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>
