Mark Phippard wrote:
> On Tue, Nov 18, 2008 at 4:09 PM, Purple Streak
> <mrpurplestreak_at_googlemail.com> wrote:
>> Is this true from the SVN book...
>> "In Subversion 1.5, once a --reintegrate merge is done from branch to
>> trunk, the branch is no longer usable for further work. It's not able
>> to correctly absorb new trunk changes, nor can it be properly
>> reintegrated to trunk again. For this reason, if you want to keep
>> working on your feature branch, we recommend destroying it and then
>> re-creating it from the trunk"
>> So once you reintegrate that means the branch is dead (which means you
>> must merge everything back in one go and start a new branch)?
> Yes and no.
> The idea is that branches are cheap and it makes sense to "re-branch".
Whups. Branches are cheap in terms of repository space and time, but
*not* cheap in terms of making sense of tangled history. The one is
handled automagically by the code, the other causes inflammation of
developers' brains. Better then to let *one* developer get her brains
inflamed while figuring out how to write code that detects when
--reintegrate is needed.
> If you do not re-branch the point is that you cannot simply do
> another synch up merge with trunk as you had been doing before. If
> you do, then it will attempt to merge back the merge you did from the
> branch. So you either need to do a 2-URL merge to synch trunk back to
> the branch or perhaps a --record-only merge in the branch so that it
> does not try to merge it back.
So basically, you need to reintegrate back and forth between the two
> From a documentation point of view, I think it makes sense to
> recommend that users re-branch.
I can't say that I agree ... people will say, based on the
documentation, that SVN is stupid if it can't support more than one
merge-back from a branch. Not the sort of expectation you want to set.
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-18 22:35:13 CET