git-svn for vendor branches?

git-svn for vendor branches?

[David A. Greene]

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

Re: git-svn for vendor branches?

[Avery Pennarun]

On 6/12/08, David A. Greene <greened@obbligato.org> wrote:
>  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.

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 :)

>  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.

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