On 27 March 2012 12:15, Joel de Guzman <joel@boost-consulting.com> wrote:
Ok, so if it can't be done with git-svn. Is there no other way to do it then?
What you guys want is for the whole of Boost to migrate en-masse to Git because it's the Git way? All or nothing? In one fell swoop?
I'm willing to migrate. I appreciate the benefits of a DVCS. I can convince my fellow Spirit/Phoenix/Fusion devs to migrate. But if you are telling me that I also have to convince all the other Boost libraries to migrate en-masse, then that is simply absurd!
That's what happened for the CVS to subversion migration, and it's pretty much what the boost steering committee was established for. But it isn't too hard to cope with transferring changes in a single direction. So if *all* development for a library does migrate to git, it's relatively easy to transfer changes from git to subversion. It depends on how accurate you need the subversion history to be. The problem is that subversion history needs to be linear, and git history generally isn't. I think it wouldn't be too hard to generate a linear series of patches with merged branches represented by a single commit, and then apply those patches to subversion. I'm not sure if that is a good idea just yet, because if there is a big migration, then your git repository will need to reconciled with the new git repository.