RE: Merge and record-only question

From: Asher Stern [mailto:astern7_at_gmail.com]

Sent: Wednesday, May 16, 2012 12:07 PM

To: Varnau, Steve (Seaquest R&D)

Cc: Stefan Sperling; Stephen Butler; users_at_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.varnau_at_hp.com>

> -----Original Message-----

> From: Stefan Sperling [mailto:stsp_at_elego.de]

> Sent: Wednesday, May 16, 2012 5:13 AM

> To: Stephen Butler

> Cc: Asher Stern; users_at_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
Received on 2012-05-16 21:36:34 CEST