qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Qpid M2 Branching / C++ 0.9 Merging
Date Thu, 08 Mar 2007 03:03:04 GMT
Robert Greig wrote:
> On 07/03/07, Andrew Stitcher <astitcher@redhat.com> 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 


View raw message