On 6/12/08, David A. Greene <greened@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
