[Nut-upsdev] Eaton_SDK dangling branch solved

[Charles Lepple]

On Jan 4, 2012, at 10:29 PM, Eric S. Raymond wrote:

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

Steps 1-3 are what I was calling Eaton_SDK at n-1 (I haven't messed with any of the delete commands to see what the exact reposurgeon name would be).

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

I was assuming this commit would be from the trunk alone - not from the n-1 branch. But git-svn seems to have given that commit two parents:

https://github.com/clepple/nut/network (scroll to Nov. 24th)

I'll have to look at the metadata.

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

To be honest, I wasn't expecting this much of a mess after the CVS-to-SVN conversion :-)

> # 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'll look, but these also seem to be from the CVS era - in which case, the CVS-to-SVN conversion might have created one single commit from where two should have been.

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

Finding more merges is still on my todo list. As you have seen, it's not as simple as just reading the commit messages to determine intent. Or, to turn the problem around, are there specific merges that you would expect to be clean? (It always seems that we're editing out a conflict or two after branches diverge.)

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

IMHO, any line endings other than Unix line endings in this repository are wrong :-) But maybe I'm just bitter that we haven't gotten the Windows_port branch to a state where we can completely cross compile it on a real system.

Realistically, we should end up with Unix line endings for most of the source, with a few Windows files which have CR/LF. I think Git on Windows shifts the burden to the editors (by storing whatever was put into the repository).

-- 
Charles Lepple
clepple at gmail