[plt-dev] Migrating branches to git

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