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 _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
