On Tue, Jul 12, 2011 at 11:55 AM, Andy Singleton <andy_at_assembla.com> wrote:
> On 7/12/2011 11:43 AM, Stefan Sperling wrote:
>>
>> On Tue, Jul 12, 2011 at 11:29:57AM -0400, Andy Singleton wrote:
>>>
>>> If you want to keep it as a mergeable branch (clearly relevant),
>>> then maybe it's better just to add on as "svn newmerge" from the
>>> beginning. If that approach is recommended, then maybe someone can
>>> help by adding the stub for this command to "svn".
>>
>> Adding such a stub will be the easiest of all tasks that lie before
>> you and your team. So if you need a new subcommand, I would suggest
>> to add the necessary stub code yourself, if only to get your feet
>> wet with the Subversion code base.
>>
>> I don't mind new subcommands in principle, but I would oppose
>> 'svn newmerge' as a name for a new subcommand. 'newmerge' is a
>> good working title but not a good name for a subcommand.
>>
>> Overall, I'd prefer solutions which change 'svn merge' in a
>> backwards-compatible manner.
>
> In my proposal, to if you decide to switch from "merge" (with subtree
> merginfo properties) to "newmerge" (with merge_history file), you would just
> make a new branch that has the merge_history, and then use newmerge from
> that point on. Three points help you make the transition:
Hi Andy,
I'm curious as to what others think, but in my experience both of
these first two points are not universally valid and thus not very
safe assumptions:
> * On most Subversion teams merging is done by relative experts. They can
> make a choice about which merge to use.
I've seen plenty of cases where the personnel charged with merging are
anything but experts. If the 'mergers' are experts why can't a policy
solution of "only merge to branch roots' solve most of the problems
you raise? Because if you do that the subtree mergeinfo problem
neatly disappears (because there is none[1]). Ok, I won't ask this
question again (today at least ;-)
[1] I'm hand waving a bit if you have pre-existing subtree mergeinfo,
but for newly created branches that shouldn't be an issue.
> * Branches in svn are often fairly short-lived, because of the cyclic merge
> problem. So, you frequently get an opportunity to make this change.
Maybe in terms of sheer branch count, but there are plenty of folks
using long-lived feature branches.
> It is not possible to make the new architecture compatible with the old
> merginfo. The subtree merginfo has been the cause of many problems,
> complexities, and fixes.
I'm still not sure what the existing problems inherent to subtree
mergeinfo you are talking about. Have you tried some of your problem
cases with a recent trunk (1.7) client? This is why I asked for some
new tests for our test suite.
At the start of your thread you said, "* It does not support subtree
merges, merges to mixed working copies, or subtree/file merginfo. I
think those cases cause a lot of complexity and are usually unwise. If
you want to work on a subtree, then you can branch or clone the
subtree and merge it back to the complete tree."
I agree on the complexity, that is why we suggest merging to the roots
of branches only. I'll even agree on using "subtree mergeinfo" as a
curses, but I'd like to see more examples of why subtree merges are
"unwise" in 1.7.
Thanks,
Paul
> It is not extensible to track more information for
> cyclic merges or tree mapping. It makes tree mapping more difficult.
> Abandoning merginfo will lift a big weight from the people working on
> merge, and make them more successful.
>
> It is possible to force the conversion by detecting old merginfo and writing
> some of it into the new branch-based merge_history file.
>
> This Apache team will decide when to deprecate the merge with the
> old/existing merginfo format. In 1.7 you have a warning about merging to
> mixed-revision working copies. You could use a similar approach for
> merging.
>
> Yes, I think it is important for users to be able to make their own
> variations and improvements of merge, especially early in the lifecycle. Is
> it easier for people to build "svn" with "svn newmerge", or is it easier
> for them to build from the packaging as a stand-alone executable?
>
> --
> Andy Singleton
> Founder/CEO, Assembla Online: http://www.assembla.com
> Phone: 781-328-2241
> Skype: andysingleton
>
Received on 2011-07-12 19:12:21 CEST