Charles Lepple <[email protected]>: > Steps 1-3 are what I was calling Eaton_SDK@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 <[email protected]> 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> _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
