Forgive me for seeking Cliff Notes, but if we've only used branches as "tags" -- to wit, branches but no merges -- are we ok without additional action on our part?
Thanks, Dave On Apr 10, 2010, at 1:15 PM, Eli Barzilay wrote: > There is a problem with migrating branches "properly" to git. (If you > don't care about branches, past or present, you can skip reading the > rest of this message.) > > The problem comes from subversion's non-existent recording of merges > (at least pre-1.5, but also post 1.5 it looks like `svn:mergeinfo' > it's not always reliable). The short story is that when you copy a > file (as happens when you create a branch by copying the trunk), then > subversion keeps the original path it came from, but when you merge > changes from a branch to the trunk, then from the svn pov this is just > like any other commit on the trunk, no formal relation to the branch > it came from. > > By now I tried a good number of tools, with numerous configurations > and tweaks, and none of them did the right thing wrt branch merges. > (Debugging this process is extremely expensive: *fast* tools do a > conversion in about 2-3 hours, slow ones take about 12-15 hours.) So > I'm giving up on this and going back to mirror *only* the trunk and > the release tags. > > Note that this means losing some historical commit information (ie, > their diff and the log message), but there is no loss of actual > files. For example, say that svn has these revisions: > > ... > r10: change on the trunk > r11: copy trunk to branches/foo/bar > r12: change on branches/foo/bar > r13: change on the trunk > r14: change on branches/foo/bar > r15: merge branches/foo/bar to the trunk (which is a change on it) > r16: change on the trunk > ... > > the log history that you will see in git (by default, unless you do > the below) is: > > ... > r10 > r13 > r15 > r16 > ... > > with the corresponding log messages. > > > This leaves two problems that need solutions: > > 1. Branches that are still live > > 2. Branches with merges that people actually care to preserve in the > git history. > > So if you have branches in either of these categories, you need to > read on. Note in particular the first point: if you have a live > branch that was not merged into the trunk you *NEED* to tell me about > it. (If you don't then it's still possible to recover: just finish > your work and create a patch based on svn which I'll apply on the git > tree, but it's better to deal with it now.) > > 1. If you have a live branch, you need to tell me its name (= its > path). What I will do is arrange for the conversion to preserve > your branch, which will create it on the central git repository. > Then when it goes live, you will clone the git repository including > your branch, and finally I will remove the branch from the server > (since they're all individual-work branches). > > 2. If you have branches that you care to include their historical > information in git, you need to mail me the following information > for every branch and merge point you want to preserve. (This works > only for branches that are copies of trunk.) > > * The branch name > * The revision it was created in > * the last revision that took place on it > * The revision number where it was merged to the trunk > > (I will then use this information to force the same ancestry > structure in the git repository using grafts.) > > It is also possible to deal with more complicated multiple branches > (ie, you created foo/bar1, worked some, merged it and the trunk > into foo/bar2, etc) -- in such cases you will need to tell me the > exact topology too, in similar terms to the above. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
