On Mon, Jan 2, 2012 at 3:52 PM, Eric S. Raymond <[email protected]> wrote: > Charles Lepple <[email protected]>: >> Hmm, this is what I get: >> >> [...] >> * Dumped revision 3363. >> * Dumped revision 3364. >> * Dumped revision 3365. >> reposurgeon "script nut.lift" "write nut.fi" >> reposurgeon: verbose 1 >> reposurgeon: from >> nut.svn...copynodes:+filemaps:copysets+commits:reposurgeon: >> r530~branches/reportbuf/drivers/nitram.h: permission information may be lost. >> +branches+++++tagifying+polishing++resets+renumbering+...(147.92 sec) done. >> reposurgeon: 2012-01-02T10:45:18 * nut.svn >> reposurgeon: event 16173 cannot be modified >> make: *** [nut.fi] Error 1 > > We seem to be out of synchronization somehow. I just rebuilt nut.svn from > the repo mirror and re-rean the conversion, and it's working fine here. > I have uploaded 2.0-pre4 to > > http://www.catb.org/esr/nut-conversion/nut-conversion.tar.gz > > Please download it and check that you can make a git repo with it. > If you can't, we need to figure out what is differing in our > working environments.
Sorry, I unzipped an earlier file of the same name. One side effect of trying this on another machine is that I noticed the interpreter path is hardcoded to /usr/bin/python. Could this be changed to "#!/usr/bin/env python"? Since we're mucking with $PATH to put reposurgeon in there, I think it's reasonable to assume that the proper Python 2.7.x interpreter will be there, but it isn't always installed to /usr/bin. > After fixing the code so it doesn't remove those junk commits until > *after* mapping Subversion branches to git branches, I still had two > detached branches - rst-old and Eaton-SDK. I then put in code to > rename each directory branch copy target almost as you suggest, except > that I used consecutive small integers rather than rev numbers. Agreed, small integers are easier to grok. Here's the story on the Eaton-SDK branch: only the tip commit is valid, and it is a collapsed set of patches (just r3330) against SVN trunk r3325. It has not been merged into the trunk. I would expect that the revisions 3323, 3324 and 3325 would form an isolated branch (Eaton-SDK@n-1) that is deleted in r3329. If that fragment gets taken out as collateral damage, I think we're okay with that, but in general I think you would want to save stuff like that in case it uncovers another corner case. Here's an excerpt of the timeline: http://trac.networkupstools.org/projects/nut/timeline?from=11%2F24%2F11&daysback=5&author=fbohe-guest&changeset=on&wiki=on&update=Update The rst.old branch was created by renaming branches/rst: http://trac.networkupstools.org/projects/nut/changeset/1138/branches/rst.old There shouldn't have been any file/metadata changes there, just renaming. > Here's the thing: that *didn't* reconnect the remaining detached branches. So > something else is going on there, some corner case that has nothing > directly to do with re-using branch names in that way. What I'm trying > to work on now is understanding what is actually going on in that case. > > The other reason I'm less sure we need to do anything special is that I've > been thinking about what you said about not trusting the metadata around > those branch renames. Er...in the import-stream world, there *isn't* any > metadata to get lost, other than file permissions. As long as the repo > translation continues to associate the same file content and permissions > with each historical revision, there basically isn't anything else to > screw up. We forgot one potential source of metadata misinformation: the commit message body. Here's an example of a relatively clean merge: SVN r3359 (2011-12-13T17:47:[email protected]) on the trunk is a merge from nut-scanner_dlopen at r3357, not r3358 as might be inferred from the commit message. The annoying part about SVN is that there is a r3358 on /every/ active branch in the repository, including the nut-scanner_dlopen branch which was last changed at r3357. r3357 = 2011-12-13T08:02:[email protected] (Is there a file with mappings between SVN revisions, Git hashes, and reposurgeon commit IDs? I think that would be very useful, especially when referring to revision info from old emails.) > If you could come up with a couple of known-good clean merges - that > is, pairs of branch source commits and trunk target commits - that > would be useful for my testing. apcsmart-dev -> trunk: merged in SVN r3211 (2011-09-12T13:54:[email protected]) - trunk parent: r3206 (2011-09-12T02:15:[email protected]) - branch parent: r3210 (2011-09-12T13:04:[email protected]) The apcsmart-dev branch has not been deleted yet. I wouldn't call the AsciiDoc merge "clean" - as I recall I had to resolve some conflicts, but I can extract pairs of commit IDs a bit easier if I could pull them from the sort of mapping file described above. Same sort of thing with the Augeas branch, although I didn't merge that myself so I don't know offhand if there were conflicts. Also, the last commit on the branch was the branch deletion. http://trac.networkupstools.org/projects/nut/log/branches/Augeas?rev=3365&mode=path_history I wonder if a branch deletion would best be represented as an annotated tag in Git? This would preserve any commit messages, without having a stub commit which does nothing except delete all the files. If the branch was merged, that stub commit would inaccurately imply (topologically) that there was further development along the branch. -- - Charles Lepple _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
