git-svn for vendor branches?

I've been reading some things about git-svn and am wondering if it could be used to manage vendor branches where both the upstream and local repositories are in svn (don't ask, I didn't set this stuff up).

My situation looks something like this:

upstream repo (svn)
  trunk
  tags
    release-1.0
    release-1.1
    release-1.2
    ...
  branches
    release-1.0
    release-1.1
    release-1.2
    ...

local repo (svn, copy of upstream via svn_load_dirs)
  trunk
  tags
  branches
    release-5.6
    release-5.7
    ...

In the past, we have updated our local trunk from the upstream trunk via svn_load_dirs/svnmerge. This works ok. Not good by any means but it's at least functional.

The problem really gets unsolvable with svn when you start looking at merging from upstream *branches.* In that case, what's in the branch/tag is something that appears nowhere on the upstream trunk. At some point it was branched from trunk and stuff was cherry-picked into it from trunk as bugs were fixed for release. So one can't just do an svn_load_dirs from trunk at the point of the branch/tag. And one can't svn_load_dirs from a release branch and then svn_load_dirs from trunk later because svn_load_dirs by its very nature aggregates lots of individual revisions into one giant one. There's no way to do the merge without a horrible number of conflicts, most of which are spurious.

We really do need to merge from a release branch into our local repository and in the future do merges from later release branches or from trunk.

If everything was in git, this would all be nearly trivial.

But it's not and I have to deal with it.

Now, there is a git mirror of the upstream repository, presumably kept in sync via git-svn. So my question is, can I somehow do a git-clone of this repository and then use git-svn to "bounce" it into our local svn repository to do merges? My reading so far tells me "no" but I wanted to check with the gurus. I believe git-svn only knows about one svn repository and in this case it would be the upstream svn that feeds the public git mirror.

I don't know how people handle this kind of need with svn.

Thanks for your help!

                              -Dave

On 6/12/08, David A. Greene <greened@obbligato.org> wrote:

Although git-svn does have ways of supporting multiple repositories, I'm not really sure git will help much here. The confusion above seems to be that fixes were cherry-picked from trunk into release branches, and now you want to merge release branches together. Neither git nor svn tracks cherry picks explicitly, and so they have about the same problems and conflicts when attempting to merge in such situations.

If I'm wrong about this, I'm sure other people on the list will enlighten me :)

But the above is a bit easier. It sounds from the above like most of the cherry-picking difficulties are incurred by the *upstream* maintainers, ie. not you. Great! That means someone is already resolving those conflicts for you and producing pre-merged releases.

If I understand correctly, all you really want to do is have your local repo contain "some upstream branch that you might want to switch occasionally" + "my local changes". This is quite elegant to do in git with git-rebase (if your local repo switches to git), but it's not even so hard to do in svn.

Basically, you just do an svn merge into your local branch of the differences from (oldbranch@oldrevision) to (newbranch@newrevision). In other words, let's say your current local version is:

    release_1 + local_patches

If you then apply the changes from release_1 to release_2, you then have:

   release_1 + local_patches + release_1..release_2
  = release_1 + release_1..release_2 + local_patches
  = release_2 + local_patches

This method works for any two svn versions release_1 and release_2. You can bounce back and forth between the trunk and a release branch, or downgrade from release_2 to release_1. The only conflicts you should get are the (unavoidable anyway) conflicts between your local changes and the changes between the two remote branches.

You can either produce the diff between release_1 and release_2 using "svn diff" on the remote repo and use plain "patch" to apply them to the local copy, or else git_load_dirs the two revisions on your local copy and "svn merge" (not "svnmerge") between the two. The latter makes it easier to resolve conflicts.

Have fun,

Avery