On Tue, Jul 12, 2011 at 11:55 AM, Andy Singleton <a...@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 >
