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

Tue Jan 3 03:30:08 UTC 2012

On Mon, Jan 2, 2012 at 3:52 PM, Eric S. Raymond <esr at thyrsus.com> wrote:
> 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.

Sorry, I unzipped an earlier file of the same name.

One side effect of trying this on another machine is that I noticed
the interpreter path is hardcoded to /usr/bin/python. Could this be
changed to "#!/usr/bin/env python"? Since we're mucking with $PATH to
put reposurgeon in there, I think it's reasonable to assume that the
proper Python 2.7.x interpreter will be there, but it isn't always
installed to /usr/bin.

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

Agreed, small integers are easier to grok.

Here's the story on the Eaton-SDK branch: only the tip commit is
valid, and it is a collapsed set of patches (just r3330) against SVN
trunk r3325. It has not been merged into the trunk.

I would expect that the revisions 3323, 3324 and 3325 would form an
isolated branch (Eaton-SDK at n-1) that is deleted in r3329. If that
fragment gets taken out as collateral damage, I think we're okay with
that, but in general I think you would want to save stuff like that in
case it uncovers another corner case.

Here's an excerpt of the timeline:

http://trac.networkupstools.org/projects/nut/timeline?from=11%2F24%2F11&daysback=5&author=fbohe-guest&changeset=on&wiki=on&update=Update

The rst.old branch was created by renaming branches/rst:

http://trac.networkupstools.org/projects/nut/changeset/1138/branches/rst.old

There shouldn't have been any file/metadata changes there, just renaming.

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

We forgot one potential source of metadata misinformation: the commit
message body.

Here's an example of a relatively clean merge: SVN r3359
(2011-12-13T17:47:31Z!arnaud.quette at free.fr) on the trunk is a merge
from nut-scanner_dlopen at r3357, not r3358 as might be inferred from
the commit message. The annoying part about SVN is that there is a
r3358 on /every/ active branch in the repository, including the
nut-scanner_dlopen branch which was last changed at r3357.

r3357 = 2011-12-13T08:02:32Z!arnaud.quette at free.fr

(Is there a file with mappings between SVN revisions, Git hashes, and
reposurgeon commit IDs? I think that would be very useful, especially
when referring to revision info from old emails.)

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

apcsmart-dev -> trunk: merged in SVN r3211
(2011-09-12T13:54:55Z!msoltyspl-guest at alioth.debian.org)
 - trunk parent: r3206 (2011-09-12T02:15:45Z!clepple+nut at gmail.com)
 - branch parent: r3210 (2011-09-12T13:04:33Z!msoltyspl-guest at alioth.debian.org)

The apcsmart-dev branch has not been deleted yet.

I wouldn't call the AsciiDoc merge "clean" - as I recall I had to
resolve some conflicts, but I can extract pairs of commit IDs a bit
easier if I could pull them from the sort of mapping file described
above.

Same sort of thing with the Augeas branch, although I didn't merge
that myself so I don't know offhand if there were conflicts. Also, the
last commit on the branch was the branch deletion.

http://trac.networkupstools.org/projects/nut/log/branches/Augeas?rev=3365&mode=path_history

I wonder if a branch deletion would best be represented as an
annotated tag in Git? This would preserve any commit messages, without
having a stub commit which does nothing except delete all the files.
If the branch was merged, that stub commit would inaccurately imply
(topologically) that there was further development along the branch.

-- 
- Charles Lepple