Re: Trying to sync two svn repositories with git-svn (repost)

On Wed, Apr 29, 2009 at 6:37 PM, Josef Wolf <jw@raven.inka.de> wrote:

Okay, I think perhaps you're missing something that took me a long time to figure out about git-svn, but once I understood it, my life went a lot more smoothly.

Basically, 'git svn fetch' updates just a *remote* branch. (Remote branches are in .git/refs/remotes/* and you can't change them yourself, because you can't attach your HEAD to them. If you try to check them out, you get the latest revision in that branch, but your HEAD becomes detached.)

I'm not actually sure which of the above branches you're referring to is remote and which is local. Let's guess that first-svn/trunk is remote, and first-svn is a local copy of it, onto which you cherry-picked some extra patches.

Some people like to think of just making a copy of the git-svn remote branch, doing stuff to it, and then doing git-svn dcommit and/or rebase on that branch. This sounds good, but it makes a mess *if* you're doing any kind of git merging (which many git-svn users never do, but which it seems you'd like to do extensively). Remember: git merge is 100% totally incompatible with rebasing.

What I'm suggesting is that you think of your local branch (first-svn in this case, I guess) as *not* an svn branch at all. You never do any git-svn operations directly on this branch. In fact, rename it to master so you aren't tempted to get yourself into trouble.

Now, you've merged from first-svn/trunk and cherry-picked some extra stuff onto this branch, right? Good. Now you want to *merge* this branch into first-svn/trunk, producing just *one* new commit, and dcommit that into svn.

   git checkout first-svn/trunk
      # detaches the HEAD
   git merge master
      # produces a merge commit on the detached HEAD
   git svn dcommit
      # produces a *different* commit object on the first-svn/trunk branch
      # ...and moves HEAD to it.

The newly-produced commit tells git that first-svn/trunk is now up-to-date with master. Note that the interim merge commit (produced by 'git merge') is never shared with *anyone*, so it's perfectly okay that we replace it with the next command.

What you probably thought you should do, given that the existing git-svn documentation says to do it, is more like this:

   # WRONG
   git checkout first-svn
   git cherry-pick some stuff
   git merge [perhaps -s ours] second-svn/trunk
   git svn dcommit

But the above will *change* every single commit you put on first-svn, because dcommit needs to *regenerate* all the commits after putting them into svn and getting them back again. This is essentially a rebase, and disrupts any merges you might have made from this branch to another one. Next time you merge, you'll get a zillion conflicts.

This is true and yet not true. The reason I don't have to ever use 'git svn rebase' is that 'git svn fetch' updates my first-svn/trunk branch, and then I quickly do a merge-then-dcommit on that branch. If I was to do a 'git svn rebase' first, nothing would happen, because svn doesn't change.

This is important, since 'git svn dcommit' actually *does* do a 'git svn rebase' for you automatically, trying to be helpful.

Yeah, they're trying to keep things simple, at the cost of preventing you from doing anything complicated. I'm not smart enough to do both, so I'm just making things complicated for you here ;)

As it happens, I wrote the git-svn chapter for the very-nearly-available new O'Reilly book "Version Control with Git." I gave the complicated solution there too. I'm eagerly awaiting the giant flames from people who actually wrote git-svn (and its documentation) and therefore are highly qualified to disagree with me.

No no!  Stop rebasing!

You have a branch that looks the way you want, right? That means you're 99% of the way there. You just have to convince git that this branch and the svn branch are related to each other in the way they actually are.

To do that, you just need to do is make a single merge commit on your svn remote branch that looks the way you want and merges from your existing branch, then do a single 'git svn dcommit'. Here's one way (assuming you want to make svn look like your new local branch):

   git checkout my-local-branch
   git merge -s ours svn-branch
   git checkout svn-branch
   git merge --no-ff my-local-branch
   git svn dcommit

(If the occasionally-suggested '-s theirs' merge strategy existed, you could just do the last three steps using git merge -s theirs.)

In fact, it *only* affects the svn log. Otherwise svn log ends up with a useless commit that says "Merged from commit (giant hex string)", and you can't actually do anything with the giant hex string because svn doesn't know what it is.

If nobody looks at your svn changelog, it's irrelevant.

There is, if you're willing to do it. The usual way is two have two branches: public and private.

Whenever you make a change that you want to be public, you commit it on the public branch, then merge (git merge or svn merge, it doesn't matter) from public to private. If you want to make a private change, you just commit it directly to private.

This way, you will always have the two sets of changes isolated, you never have to cherry-pick anything, and "git diff public private" is always a sensible thing to do.

(In fact, when I do this, I often don't share the private branch with anyone at all, which means it's safe to rebase. That means I can keep a clean set of patches against the public branch, and sort and rearrange or share them whenever I feel like it. This is useful in some cases. Rebasing isn't *always* bad :))

On branch b, 'git merge x' will always merge all the changes from the most recent merge of x into b (which might be a "-s ours" merge if you want), up to the tip of x. So if you don't commit any *new* private stuff to x, you can use merge. If you're intermixing the changes, you'll need to use cherry-pick. git won't attempt to track the cherry-picks for you (like eg. svnmerge will).

Have fun,

Avery