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:
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
> * 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). Ok, I won't ask this
question again (today at least ;-)
 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.
> 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
> 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