5

My team uses SVN for source control. Recently, I've been working on a branch with occasional merges from the trunk and it's been a fairly annoying experience (cf. Joel Spolsky's "Subversion Story #1"), so I've been looking alternative ways to manage branches and merging. Given that a centralized SVN repository is non-negotiable, what I'd like is a set of tools that satisfy the following conditions.

  1. Complete revision history should be stored in SVN for both trunk and branches.

  2. Merging in either direction (and potentially criss-crossing) should be relatively painless.

  3. Merging history should be stored in SVN to the greatest extent possible.

I've looked at both git-svn and bzr-svn and neither seems to be up to the job—basically, given the revision history they can export from the SVN repository, they can't seem to do any better a job handling merges than SVN can. For example, after cloning the repository with git, the revision history for my branch shows the original branch off of trunk, but git doesn't "see" any of the interim SVN merges as "native" merges—the revision history is one long line. As a result, any attempts to merge from trunk in git yield just as many conflicts as an SVN merge would. (Besides, the git-svn documentation explicitly warns against using git to merge between branches.)

Is there a way to adjust my workflow to make git satisfy the above requirements? Maybe I just need tips or tricks (or a separate merging tool?) to help SVN be better at merging into branches?

Chris Conway
  • 55,321
  • 43
  • 129
  • 155
  • Sounds like you really need to just convince your team to use git. :P – Amber Mar 29 '10 at 05:22
  • 2
    I think, unfortunately, that you're running up against the fact that SVN is simply limited in its ability to merge branches - and as long as your central repo is an SVN repo, it's hard for any amount of git magic to save you. I'm certainly curious to see if there are any good working kludges though! – Cascabel Mar 29 '10 at 05:23

1 Answers1

2

Without having a pure SVN answer, I would like to refer to the SO question "How to fool git-svn to recognize merges made with svn?"

I recommended doing those git merges in a special branch, but a simpler solution would be to record (at least the most recent) SVN merges in the git-svn cloned repo with git grafts file, in order to transform:

  o-...-A---o---D--- unstable
 /       
X-----B---M---o---o--- stable

into:

  o-...-A---o---D--- unstable
 /       \ 
X-----B---M---o---o--- stable

, easing the git merge process, before dcommit and sending that back to SVN.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • The grafts file seems to help a lot, thanks! It seems to be sufficient to add a graft for just the last merge from trunk. Is that right? Do you recommend using `git merge --squash` to hide the true DAG from SVN? Also, I wonder how well this satisfies #3 (though honestly I'm not sure how valuable having the mergeinfo is to SVN)? – Chris Conway Mar 29 '10 at 13:25
  • @Chris: after reading http://stackoverflow.com/questions/2427238/in-git-what-is-the-difference-between-merge-squash-and-rebase, I don't think a `merge squash` is necessary here. SVN can use the DAG to record some `mergeinfo` metadata during `dcommit`. – VonC Mar 29 '10 at 16:29