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

[Charles Lepple]

On Dec 31, 2011, at 9:20 AM, Eric S. Raymond wrote:

> I've solved the detached-branch problem! It wasn't actually the
> branch-rename overwrites that were doing this - turns out I was trying 
> to remove cvs2svn-generated junk commits too soon and in the process
> deleting critical branch links.
> 
> I've uploaded a new tarball to 
> 
> http://www.catb.org/esr/nut-conversion/nut-conversion.tar.gz
> 
> with the 2.0-pre3 version of reposurgeon in it.

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

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

> 2. Branch merge detection.

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.

-- 
Charles Lepple
clepple at gmail