I appreciate all the replies I have received -- even the off-topic ones have been informative. Yours is especially valuable. Thank you, DarkForge, for bringing the very important lack of cyclic merges to my attention. The advice from the svn book (page 94 of r3212) is as follows:
At the time of writing (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 ab-
sorb 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..."
Surely they're joking. Workflow must drive tools, not the other way around. Unless something like TortoiseSVN automates
svn merge --reintegrate
svn delete %old branch%
svn copy %new branch%
this is really going to kill svn going up against ClearCase. Too bad. Mercurial and the other distributed SCM's are not an option for us, because we use a *lot* of binary data which changes often. So for our business needs, the centralized server paradigm still fits well, especially since we have professionally managed bandwidth and server storage in our organization. ClearCase wins, as the pig with the prettiest dress.
Slashdot Mirror
Surely they're joking. Workflow must drive tools, not the other way around. Unless something like TortoiseSVN automates
svn merge --reintegrate
svn delete %old branch%
svn copy %new branch%
this is really going to kill svn going up against ClearCase. Too bad. Mercurial and the other distributed SCM's are not an option for us, because we use a *lot* of binary data which changes often. So for our business needs, the centralized server paradigm still fits well, especially since we have professionally managed bandwidth and server storage in our organization. ClearCase wins, as the pig with the prettiest dress.