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