[Nut-upsdev] I've solved the detached-branch problem

[Eric S. Raymond]

Charles Lepple <clepple at gmail.com>:
> Hmm, this is what I get:
> 
> [...]
> * Dumped revision 3363.
> * Dumped revision 3364.
> * Dumped revision 3365.
> reposurgeon "script nut.lift" "write nut.fi"
> reposurgeon: verbose 1
> reposurgeon: from nut.svn...copynodes:+filemaps:copysets+commits:reposurgeon: r530~branches/reportbuf/drivers/nitram.h: permission information may be lost.
> +branches+++++tagifying+polishing++resets+renumbering+...(147.92 sec) done.
> reposurgeon: 2012-01-02T10:45:18 * nut.svn
> reposurgeon: event 16173 cannot be modified
> make: *** [nut.fi] Error 1

We seem to be out of synchronization somehow.  I just rebuilt nut.svn from
the repo mirror and re-rean the conversion, and it's working fine here.
I have uploaded 2.0-pre4 to

http://www.catb.org/esr/nut-conversion/nut-conversion.tar.gz

Please download it and check that you can make a git repo with it.
If you can't, we need to figure out what is differing in our 
working environments.
 
> > That leaves two remaining issues.
> > 
> > 1. Exactly what *is* the right way to handle branch copies that re-target
> > an existing branch name?
> 
> Notionally, I like the git-svn idea of having "branch-name at rev", with the latest branch dropping the "@rev" part. With the reposurgeon commit ID format in mind, I could see using an ISO timestamp, but the username is probably not necessary. Since renaming branches is not an O(N) operation, I think that dropping the @rev for the most recent branch could be done in a separate pass.

I am actually no longer sure we need to do anything special at all. Here's why.

I found out that the reason I had a whole bunch of detached branches in my
conversion wasn't because of these directory overwrites. It was because I was 
clobbering cvs2svn-generated branch-root commits too early, and they were 
taking branch-linkage information with them.

After fixing the code so it doesn't remove those junk commits until
*after* mapping Subversion branches to git branches, I still had two
detached branches - rst-old and Eaton-SDK.  I then put in code to
rename each directory branch copy target almost as you suggest, except
that I used consecutive small integers rather than rev numbers.

Here's the thing: that *didn't* reconnect the remaining detached branches. So
something else is going on there, some corner case that has nothing
directly to do with re-using branch names in that way.  What I'm trying
to work on now is understanding what is actually going on in that case.

The other reason I'm less sure we need to do anything special is that I've
been thinking about what you said about not trusting the metadata around
those branch renames. Er...in the import-stream world, there *isn't* any
metadata to get lost, other than file permissions.  As long as the repo 
translation continues to associate the same file content and permissions
with each historical revision, there basically isn't anything else to
screw up.

> I still haven't had a chance to really look at the different merge
> points, but I would not mind just manually entering merge
> information for now (since we didn't do all that many merges in this
> repository). Other projects might be better test cases for automatic
> merge detection.

Yeah, I'm actually ahead of you on this.  Look at "help merge" and
consider the single-argument (automatic) and two-argument (manual) 
variants of the command.

I haven't yet found a merge that the two-argument form will pass as
clean.  This probably means my merge-validity check is wrong (too
strict) but I don't know how to make it right.

If you could come up with a couple of known-good clean merges - that
is, pairs of branch source commits and trunk target commits - that
would be useful for my testing.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>