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:
* On most Subversion teams merging is done by relative experts. They
can make a choice about which merge to use.
* Branches in svn are often fairly short-lived, because of the cyclic
merge problem. So, you frequently get an opportunity to make this change.
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. 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 17:55:52 CEST