From: Asher Stern [mailto:aste...@gmail.com]
Sent: Wednesday, May 16, 2012 12:07 PM
To: Varnau, Steve (Seaquest R&D)
Cc: Stefan Sperling; Stephen Butler; users@subversion.apache.org
Subject: Re: Merge and record-only question
Hi.
Thank you all for your answers.
Yet, I am not sure about my question:
If after all of this {merge --reintegrate, local changes in T, and merge
--recode-only in B} -
If later, there will be more changes / additions in B, and we will want to
merge them to T, are we going to face any problems? Problems due to the
inconsistency of T and B?
What is going to happen when we will make that merge in the future? Will the
"not merged" changes be merged in the future, and again we will have to
manually revert them, just like what we plan to do now?
There were 3 different merge plans proposed. The answer is different depending
on what you choose to do.
Option A: Your original plan (merge and then make local changes to un-do some
changes).
In this case it is still recorded in meta-data as if you merged everything, so
future merges will not try to apply those changes.
Option B: Per Stephen B (do not merge whole branch, just merge the revisions
you want aka cherry-pick).
In this case you do not need to un-do any changes at all, but in future merges,
you also need to cherry-pick, avoiding the changes you don't want.
Option C: Per (me) Steve V (first block the changes you don't want via --record
only, then merge the branch).
In this case you also do not need to manually un-do any changes, but they are
recorded as if they happened, so neither the immediate merge nor future merges
will not try to apply them.
The farther these branches diverge, the more problem you'll have merging them,
of course.
-Steve
2012/5/16 Varnau, Steve (Seaquest R&D) <steve.var...@hp.com>
> -----Original Message-----
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: Wednesday, May 16, 2012 5:13 AM
> To: Stephen Butler
> Cc: Asher Stern; users@subversion.apache.org
> Subject: Re: Merge and record-only question
>
> On Wed, May 16, 2012 at 01:57:45PM +0200, Stephen Butler wrote:
> > I'd recommend doing cherrypicking merges from B to T.
>
> I believe either of Asher's or Steven's suggestion would work fine.
>
> If you go for the cherry-pick from B to T option, you might want to
> block the resulting commits to T from being merged to B by performing a
> --record-only merge of those revisions to B. Then, fully sync B back up
> with T, and during that merge you shouldn't see much spurious conflicts,
> if any. Now keep syncing B to T regurlarly, and finally --reintegrate B
> at a later time.
>
> The most important point to consider though is how you ended up in this
> mess in the first place. Somehow you ended up with a branch B that
> doesn't contain a clean changeset. That is the real problem. You would
> pretty much have to use cherry-picking in any version control system at
> this point, so your question is not particularly specific to
> Subversion's merge.
> Obviously, there was some bad planning, or inconsiderate changes were
> made to B. You should investigate how this happened and try to prevent
> this problem from happening again (by educating developers, more careful
> planning, drinking more coffee, or whatever else will help).
It depends on the scenario. If branch B is not a feature branch per se, there
may be valid reasons to not merge back changes. Rather than just use
cherry-pick merges, it may be easier to use --record-only to permanently block
those changes from being merged. Of course, it is a good idea to put in a good
comment on that checkin to remember why the changes are being blocked. But once
you do, you can just do a branch to branch merge rather than cherry-pick.
>
> Oh, and Steve's suggestion to try out merge scenarios is a good one.
> Please don't take our word for it but try out various approaches in a
> test environment before you apply them in production.
>
> Good luck!
Agreed.
-Steve
