Well, that wasn't as nasty as I feared it would be. Turns out that in the general case it's possible to partition a mixed-branch revision into branch cliques and generate multiple import-stream commits, one for each affected branch.
We lose only if the split commit is the source of a later directory copy; I have a check for that that says, basically, "if you see this fatal error, file a bug report". The NUT repo doesn't do that. I'll be a bit surprised if I ever get such a bug report. The results look a little kludgy. The NUT Subversion commit r87 turns into two git commits with Fossil-ID headers 87.1 and 87.2. The commit corresponding to 87.2 has its commit time bumped by 1 second so all the committer/timestamp pairs will remain unique. But it will do. 2.0-pre6 and auxiliary files have been uploaded to http://www.catb.org/esr/nut-conversion/nut-conversion.tar.gz for your inspection. Remaining issues: # 1. Have yet to find a clean merge point for any branch. # 2. set-eol-style operations get lost; see tags windows-set-eol, reset-eol. # 3. Should the first Eaton_SDK commit after the deleteall have a link # back to trunk? # 4. Is the new_UIs-root tag still useful? It doesn't seem to point # at an actual branch. Also, some remaining zero-fileop commits on the root branch should probably be tagified. >From what you said before, point 2 may actually be a non-issue. Should I cross it off the list? -- >>esr>> _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
