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) <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:07:54 CEST