[Nut-upsdev] Eaton_SDK dangling branch solved

[Eric S. Raymond]

Charles Lepple <clepple at gmail.com>:
> > The correct fix is to check each new text section against a list of
> > MD5 hashes of old text sections.  If I find a match, I then fill in
> > copyfrom_path and copyfrom_rev information so it looks (for purposes
> > of parent and branch computation) as though the branch creation had
> > been done with "svn copy".
> 
> However, the original erroneous Eaton_SDK branch was deleted. The parent of the commit at "2011-11-24T08:56:56Z!fbohe-guest at alioth.debian.org" (SVN:3330) should be "2011-11-15T22:22:02Z!arnaud.quette at free.fr" (SVN:3321) on the trunk, not "2011-11-24T08:56:01Z!fbohe-guest at alioth.debian.org" (SVN:3329), which is the deletion commit (and therefore the end of Eaton_SDK at n-1).
> 
> I think the method of turning branch deletion into a tag (that tags the previous commit on that branch) will break the lineage between SVN:3329 and SVN:3330.

What is presently happening is that 

1. The Eaton_SDK branch is rooted on  2011-09-18T17:22:29!arnaud.quette at free.fr
"Add the missing '-q' option (closes Alioth patch #301145".

2. It begins with 3 commits:

Create Eaton_SDK branch
Add missing executable property
Add missing ignore property

3. It continues with a deleteall commented "Remove this branch because properties of some files are wrong"

4. It ends with a single commit, "Re-create Eaton_SDK branch with
(hopefully) rights files properties."

If you want to forget the part you think of as Eaton_SDK at n-1 (before
the deleteall) that is easy enough to arrange with a couple of deletes
- but this straight-up translation of the operations on the branch
seems to me to be the least surprising thing reposurgeon can do in the
general case.

I took your advice about turning tip branch delete into tags.  That turned
out to clean up the other bit of loose debris - the rst.old directory copy -
in a natural way.  I'm now testing some fixups on three misplaced or misnamed 
tags:

# Tag location and name fixups
delete =C & /Remove 2.6.0 tag/ obliterate quiet
tag v2.6.0 move /Missing website update for 2.6.0/
delete =T & /^wrong tag name/
tag 2.0.4 rename v2.0.4
delete =T & /re taging 2.2.2/
delete =C & /moving the tags following a last change in Testing/
tag v2.2.2 move /fix HAL_CALLOUT_PATH for distcheck/

...and my test run just popped up gitk.  It looks like those commands
had exactly the desired effect.  I had just now written the 'tag' major
command with 'move', 'rename', and 'delete' subcommands to express
them; I have no doubt it will prove useful in the future.

Here's my remaining list of known issues. Discussion follows:

# Known problems:
# 1. Anomalous commits on the root branch.
# 2. Have yet to find a clean merge point for any branch.
# 3. set-eol-style operations get lost; see tags emptycommit-3003,
#    emptycommit-2582, emptycommit-2175.

The root branch is a dumping ground for any commit for which the code
couldn't find a common directory prefix in the fileset that maps to a
branch.  As expected, it includes a bunch of junk directory copies we
can just delete.  But there are some commits on it that that have real
fileops. Here are two examples:

2005-07-27T17:19:35!arnaud.quette at free.fr  cgi enhancements step1
2005-07-22T07:44:43!arnaud.quette at free.fr  various changes on newhidups and dummy-ups

I need to figure out where in the branch topology those commits are supposed
to live and why they didn't land there.  Might be they mix file operations 
on divergent Subversion branches (groan!) in which case my branch-analysis
code is going to have to become significantly twistier. 

I have yet to find a clean merge point for any branch.  I think this means 
my cleanliness test is wrong.  I'll work on that.

I don't know what to do about the svn:eol properties.  git's handling of
cross-platfform line termination issues doesn't seem very well documented. 
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>