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

[Eric S. Raymond]

Charles Lepple <clepple at gmail.com>:
> 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.

Done.  That was a thinko on my part; you were right to object.

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

Exactly. I could solve NUT's immediate problem with meatball surgery,
but from my end doing that would miss half the point of the exercise.
It's already the case that reposurgeon, even with the problems we're
discussing, that reposurgeon 2.0 will the best tool for transitioning
out of Subversion there is - but I'm not settling for best, I want
armor-plated and impossible-to-confuse!
 
> 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.

Yes, that matches what I see.

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

OK, I should have said "same content, file permissions, and committer/
date/comment information".  Thing is those are all going to be preserved
whether we do something special near branch renames or not.
 
> 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

That's good to know.

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

You camn make one with "fossils write" adfter loading NUT svn..

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

That is also useful for me to know.

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

What I had been planning to do, in places where I could find a merge,
was to delete the tip-delete commits.  But turning them into annotated
tags would be a better idea, the way I'm already doing with branch roots.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>