[Nut-upsdev] Eaton_SDK dangling branch solved

[Eric S. Raymond]

Charles Lepple <clepple at gmail.com>:
> Steps 1-3 are what I was calling Eaton_SDK at n-1

Right, I thought so.  

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

Hm.  That makes me wonder if I should be detecting two parent links here as
well.  I'll add that to my to-do list.

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

That seems not unlikely.  The question is how I'm going to deal with
it.  For an an example of the messiness, there's a revision in the
dumpfile that looks like this (text sections have been removed):

Revision-number: 432
Prop-content-length: 173
Content-length: 173

K 7
svn:log
V 64
Patch for spec file, courtesy of William Bell (tested on RHEL4)

K 10
svn:author
V 13
clepple-guest
K 8
svn:date
V 27
2006-06-09T02:42:54.140363Z
PROPS-END

Node-path: branches/Testing/CHANGES
Node-kind: file
Node-action: change
Text-content-length: 145003
Text-content-md5: 4891f7b636fe310141bef10469585914
Text-content-sha1: 104107f973dd766bb059f4e2868dde68072058d2
Content-length: 145003

Node-path: branches/Testing/packaging/RedHat/nut.spec.in
Node-kind: file
Node-action: change
Text-content-length: 11873
Text-content-md5: a0c5db69876abac956eef20cd611f411
Text-content-sha1: 0b0b7b58d31aaa35a580c99ba0f9d24f87bbdb99
Content-length: 11873

Node-path: trunk/CHANGES
Node-kind: file
Node-action: change
Text-content-length: 162960
Text-content-md5: 1964e5c4b98da27203a362f09293dc66
Text-content-sha1: d8e1cd5a5f66664f52d4f523befddf10ae8a3cfe
Content-length: 162960

Node-path: trunk/packaging/RedHat/nut.spec.in
Node-kind: file
Node-action: change
Text-content-length: 11873
Text-content-md5: a0c5db69876abac956eef20cd611f411
Text-content-sha1: 0b0b7b58d31aaa35a580c99ba0f9d24f87bbdb99
Content-length: 11873

Here's how this translates into import-stream markup:

commit refs/heads/root
mark :1917
committer Charles Lepple <clepple+nut at gmail.com> 1149820974 +0000
data 64
Patch for spec file, courtesy of William Bell (tested on RHEL4)
from :1630
M 100644 :1914 branches/Testing/CHANGES
M 100644 :1915 branches/Testing/packaging/RedHat/nut.spec.in
M 100644 :1916 trunk/CHANGES
M 100644 :1915 trunk/packaging/RedHat/nut.spec.in

The problem is that there are paths from two different branches here,
'trunk' and 'branches/Testing'. The commit lands on the root branch
because there's no common file prefix on all the paths, which is what 
the branch analysis logic was expecting.

There are only 3 of these mixed commits out of over 3300 in the repo.
But they're a biiig problem.  The correct way to handle them *should*
be to split them up into multiple commits.  But there are headaches 
galore here, starting with a problem as basic as: what imputed Subversion
revision numbers should the fragments get?  There's no answer that doesn't
break assumptions all over the code about Subversion revision numbers 
being monotonically-increasing integers...

This is *nasty*.  I don't know how I'm going to handle it.  I don't think
there's any way to do it gracefully...

> > 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 the history well enough. But let's have this conversation again
after I've taken a whack at the mixed-commit problem.

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

Whereas under Unix git seems to use LF everywhere.  To be revisited later.
Right now I have to figure out some way to cope with those mixed commits,
because that's a showstopper.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>