On Dec 28, 2011, at 11:43 AM, Eric S. Raymond wrote: > Charles Lepple <[email protected]>: >> Great news! Is there a copy of the Git repo that I can take an early >> look at, or is this version of the reposurgeon code committed >> somewhere? > > By a happy coincidence, your reply came to my notice as I was putting > the finishing touches on that package for you. If you fetch
Got it. I will take a closer look at it tomorrow. >> There is also that issue of SVN allowing both local and remote >> copies of files to make branches, and I've always been suspicious of >> that metadata. This is particularly evident when git-svn tries to >> understand what is going on around branch creation points that were >> recreated with the same name (windows_port, etc). > > Indeed. There's one big problem in the present conversion - a > Development branch detached from trunk - which I'm almost certain is > due to this kind of aliasing. > > I think the way I'm going to have to handle this is with reposurgeon > code that recognizes branch re-creation points in the dump stream and > does something special with them - most likely refusing to delete the > old branch and instead creating a new branch with a distinguishing > suffix. The ideal name for the latest branch would be the one without a suffix, but the conversion code doesn't know that a priori. Maybe the simplest thing is to fix that up in the *.lift script? (I'm still finding my way around.) > The other problem I'm grappling with right now is merge detection. Ideally, > your feature branches should automatically or semi-automatically get merge > links back to trunk (that is, no change to content but the live end of the > branch should become the parent of some later trunk revision). I'm trying > to debug logic to do that. It's not easy. Similarly, this is something that might be best handled with a fixup command - especially since the merge metadata usually isn't stored in the Subversion repository. (Merge support came too late to be widely used, IMHO.) I think the results of editing out conflicts in a merge would make it very hard to detect anything other than the cleanest merges. > How are your Python skills? I think at this point I could use a > collaborator to help improve reposurgeon's branch-surgery and > merge-recognition code, if you're interested. They are rusty, but I'll take a look. The reposurgeon code is a lot cleaner than what I am used to. -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
