[Svnmerge] Question about SVN 1.5 vs. svnmerge

[Reid Priedhorsky]

Jon Schewe wrote:
> Reid Priedhorsky wrote:
>> Jon Schewe wrote:
>>   
>>> After having read 
>>> http://blogs.open.collab.net/svn/2008/07/subversion-merg.html I'm 
>>> wondering if I can actually use my development branches with svn 1.5 
>>> merging with one change. Each time I merge my development branch back
>>> to trunk I delete and recreate it on the server side as suggested in
>>> the article "The bottom line is that if you recreate your branches
>>> you will not run into this.  svn delete followed by svn copy runs
>>> fast, and does not take up any repository disk space.  You do not
>>> even have to do anything special to your working copy.  So just do
>>> it!"
>>>
>>> Does anyone see problems with this?
>>>     
>> I see two disadvantages with this pattern:
>>
>> 1. Extra commits and associated noise from the delete and copy.
>>
>> 2. Continuation of new work on the branch is blocked by the merge-to-trunk.
>>
>> In my case, #2 is a major problem because merging to trunk is done by 
>> the project manager, not the developer on the branch. :/ YMMV.
>>   
 >
> Those are good points to think about. #1 doesn't bother me much, #2 can
> be an issue, depending on the project. Are there any technical issues
> with this? Cases where this won't work?

My read of the 1.5 docs is that this workflow can be achieved if the 
merges in both directions (branch->trunk and trunk->branch) do _not_ use 
--reintegrate, and manually exclude revisions that are not wanted.

For us, we use the following rules under svnmerge for dealing with 
conflicts:

1. Branches merge all revisions from trunk. If conflicts arise, use the 
trunk version.

2. Trunk merges most revisions from each branch. Reflective branches are 
excluded (-b). If conflicts arise, they are manually repaired.

If I'm correct above, this would translate OK to SVN 1.5, I'd just have 
to manually exclude trunk->branch merges when merging branch->trunk.

Reid