Robert Greig wrote:
On 07/03/07, Andrew Stitcher <[EMAIL PROTECTED]> wrote:
In theory this seems correct - that is we shouldn't hold up the C++
reorg for the 0-9 merge. But the main reason we haven't done it yet is
that svn tracks renames (and moving stuff around) extremely poorly and,
this to my understanding, could make the merge extremely painful if done
afterwards.
Here's the other way to do it: I backmerge C++ from trunk to 0-9 branch
to pick up all useful work on the trunk, and we go ahead with cleanup on
the branch. We do nothing on trunk except fixes for M2 - for C++ the
trunk effectively becomes the M2 branch.
When an M2 branch is finally, M2 fix work will carry on the M2 branch.
M2 fixes on trunk or M2 branch will be individually merged out to 0-9 if
relevant, by hand if necessary due to file renames.
The 0-9 branch will be "merged" to trunk by simply replacing the trunk
with the branch. Since any changes on the trunk to C++ will already be
individually merged, there's no need for a painful merge at this point.
The only rename pain might be in merging M2 fixes, which will hopefully
be minor.
Does anyone actually have experience with doing the wholesale renaming
and moving Alan is talking about on a svn branch.
It sucks. Even simple small-scale renaming with SVN sucks.
If not for this reasoning there is a lot of clean up work that we would
already have done on the branch.
Unless there's sudden agreement to create an M2 branch, I think the
strategy outlined above will work with pretty much equivalent pain to
branching immediately. Either way we can limit the pain to individual
merges of small M2 fixes and make the major "merge" trivial.
I think it is unfortunate that our scm tool is limiting us. I would
fully support a move away from Subversion - a tool that has not IMHO
lived up to the hype around it.
RG
No kidding. Jim Meyering has experience with git and recommends it as a
good alternative, he can give more details if there's support for such a
move.
Cheers,
Alan.
