Nut upsdev - Dec 2011 - I've solved the detached-branch problem

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.

That leaves two remaining issues.

1. Exactly what *is* the right way to handle branch copies that re-target
an existing branch name?

2. Branch merge detection.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Sometimes the law defends plunder and participates in it. Sometimes the law
places the whole apparatus of judges, police, prisons and gendarmes at the
service of the plunderers, and treats the victim -- when he defends himself --
as a criminal.	-- Frederic Bastiat, "The Law"

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