On Jul 12, 2011, at 11:29 AM, Andy Singleton <andy_at_assembla.com> wrote:
> My original idea was to make a new executable file called "newmerge". It would be an external script, and if you want to use it, you just need that extra script. However, I was planning on building it from the C code that is in "svn merge" right now, rather than python or perl. Using the existing code will put us ahead on patch libraries and protocols. It will also give us access to the experts that have worked on "svn merge" in the past. And, it will be easier to integrate into GUI clients. So, the code would start as a cut-down version of "svn merge". Later it could be added back as "svn newmerge".
>
> 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".
>
> I don't think that we will need to force anyone to give up the old merge. If and when the newmerge is better, they will migrate on their own. I think merge is an important concern for many users and they will migrate quickly if they can get a better result.
>
>
> On 7/12/2011 11:00 AM, Mark Phippard wrote:
>> On Tue, Jul 12, 2011 at 10:52 AM, Julian Foad<julian.foad_at_wandisco.com> wrote:
>>
>>> A script has the advantage that it could be tried and even rolled out by
>>> people who are still using 1.6.x.
>>>
>>> None of that is a reason not to start a branch.
>> +1 on the branch. But wouldn't it make sense to defer creating the
>> branch for as long as possible? If Andy's team wants to explore
>> scripts first why create a branch that is just going to immediately
>> start getting stale? Maybe we should start with patches to trunk and
>> make the branch when there is something to not include on trunk?
>>
>> FWIW, I would also like to see more dev@ discussion and less private
>> discussion. Before we start working on a new command seems we ought
>> to discuss the ideas more. As I mentioned a new command is going to
>> need a way to force users to use the new command or else all the same
>> issues have to be addressed. If we can force users to do something,
>> then I am not sure we need a new command. We can just have a way to
>> not allow users to use the features of existing merge that we do not
>> want them to use. The existing merge command already supports the
>> proposed simple syntax.
>>
According to that vision, what happens when everyone decides to use "newmerge"? What happens to the old "merge" command?
-Geoff
Received on 2011-07-12 17:39:20 CEST