Merge and record-only question

[Asher Stern <as...@gmail.com>]

Hi.

I have a question about merge, reintegrate and record-only.

We use SVN version 1.6

I am working on trunk, let's call it T.
My colleague works on a branch (branched from trunk), let's call it B.

We want to merge back, i.e., merge --reintegrate from B to T.
However, there are some changes in B that we do NOT want to be copied to T.

We considered the following steps:
1. merge --reintegrate
2. Then, manually, in the working copy of T, revert all unnecessary changes
in B that we don't want to be merged into T.
3. Then, in the working copy of T: svn commit.
4. Then, keeping the branch B alive, by merge --record-only.
5. Now we have T and B, but they are NOT identical.
6. Continue working separately on T and B, making merges from T to B from
time to time, and eventually, after several months, making again merge
--reintegrate from B to T.

The question is whether it is possible. Is it OK that T and B will not be
identical after the reintegrate, and continue working on B?
Might such a scenario cause problems in future merges (from T to B and from
B to T)?

Thanking you all in advance,
Asher Stern

RE: Merge and record-only question

["Varnau, Steve (Seaquest R&D)" <st...@hp.com>]

From: Asher Stern [mailto:astern7@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) <st...@hp.com>

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

> From: Stefan Sperling [mailto:stsp@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

Re: Merge and record-only question

[Asher Stern <as...@gmail.com>]

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?

2012/5/16 Varnau, Steve (Seaquest R&D) <st...@hp.com>

> > -----Original Message-----
> > From: Stefan Sperling [mailto:stsp@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
>

RE: Merge and record-only question

["Varnau, Steve (Seaquest R&D)" <st...@hp.com>]

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@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

Re: Merge and record-only question

[Stefan Sperling <st...@elego.de>]

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

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!

Re: Merge and record-only question

[Stephen Butler <sb...@elego.de>]

On May 16, 2012, at 12:42 , Asher Stern wrote:

> 
> Hi.
> 
> I have a question about merge, reintegrate and record-only.
> 
> We use SVN version 1.6
> 
> I am working on trunk, let's call it T.
> My colleague works on a branch (branched from trunk), let's call it B.
> 
> We want to merge back, i.e., merge --reintegrate from B to T.

Assuming that B is a "feature branch" that should be kept consistent with T,
your colleague should merge all changes from T to B (early and often).

  http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html

I see you mention this in step 6, below.

> However, there are some changes in B that we do NOT want to be copied to T.

Then you don't want to use --reintegrate.  See the description of the
reintegrate merge in the SVN book.

I'd recommend doing cherrypicking merges from B to T.  But you don't have
to trust me. ;-)  Just create a temporary local repository, create branches
in it, and see how the merges turn out.  Create a shell or batch script to
automate the repetitive steps, and try many alternatives.  There are handy
script templates in the "Write a reproduction script" section at

  http://subversion.apache.org/contributing.html#issues

If you have more specific questions, or find a bug, it's much easier for us to 
help if you attach your reproduction script.

Regards,
Steve

> 
> We considered the following steps:
> 1. merge --reintegrate 
> 2. Then, manually, in the working copy of T, revert all unnecessary changes in B that we don't want to be merged into T.
> 3. Then, in the working copy of T: svn commit.
> 4. Then, keeping the branch B alive, by merge --record-only.
> 5. Now we have T and B, but they are NOT identical.
> 6. Continue working separately on T and B, making merges from T to B from time to time, and eventually, after several months, making again merge --reintegrate from B to T.
> 
> The question is whether it is possible. Is it OK that T and B will not be identical after the reintegrate, and continue working on B?
> Might such a scenario cause problems in future merges (from T to B and from B to T)?
> 
> Thanking you all in advance,
> Asher Stern

--
Stephen Butler
Consultant

elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Building 12
13355 Berlin, Germany

tel: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elego.de

Geschäftsführer: Olaf Wagner, Michael Diers
Sitz der Gesellschaft: Berlin
Handelsregister: Amtsgericht Charlottenburg HRB 77719