RE: Why is --reintegrate neccessary?

The problem is that we have concurrent work going on in all the different branches, and those changes need to be merged freely between the branches.

For example, when a bug is fixed in the release branch, we need the change to be propagated back to the various QA and dev branches. The only way to do this is to cherry-pick those changes, otherwise SVN will attempt to merge the previous forward-merges back into those branches. Heaven forbid you have some renames in there! It gets more complicated when you have changes going in two directions sometimes it seems like SVN wants to apply the same change twice to the same tree. As far as I can tell this is all expected behavior.

I'd like to use a free, centralized vcs that can handle merge tracking well, but I guess I'll have to wait...

Piers.

-----Original Message-----
From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
Sent: Thursday, September 23, 2010 1:34 PM
To: users_at_subversion.apache.org
Subject: Re: Why is --reintegrate neccessary?

On 9/23/2010 3:27 PM, Piers Haken wrote:
>> I'm hoping that 1.7 will address much of this...
>
> Hmmm, just to manage some expectations: I wouldn't expect too much tree-conflict or merge improvements in 1.7. There might be some small improvements here and there, but the big ones will not be in 1.7.
>
> That's very sad. I love SVN, but I'm not sure my patience will last
> for another year... :(

Maybe it is just the nature of the feature-branch model. Do you really have that much trouble with people doing concurrent work in the trunk and fixing their conflicts as they happen?

-- 
   Les Mikesell
    lesmikesell_at_gmail.com