On Tue, Jul 12, 2011 at 11:29 AM, Andy Singleton <andy_at_assembla.com> wrote:
> 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.
Setting aside for a minute the global ID idea which I realize is
probably important to you to support your proprietary repository fork
solution, the only real change in your proposal is to limit what
someone can do in merge. IOW, do not allow subtree merges, switched
merges etc. The other stuff you proposed can already be done and is
already widely used today.
I assume you would agree that you cannot have a situation where there
is a "newmerge" command that one person uses and someone else uses
"oldmerge" to do a subtree merge with the same tree. So you have to
come up with some way for a given project to decide they want to use
"newmerge" and disallow "oldmerge".
All I am saying is that if you figure out a way to impose these
restrictions we do not need a new command or subcommand. We can
simply make the existing merge honor those restrictions and you have
accomplished the goal of the simplified syntax. This is something we
have already discussed on this list in the past in the context of
adding an svn branch command to mark the root of a project tree.
To me, this is probably step 1 (and it is a fairly big but important
first step). Once we have this, we could start examining the
mergeinfo syntax and where/how it is best stored and how it could
possibly be supplemented to support reflective merges or renames or
...
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-07-12 17:54:43 CEST