On 7/12/2011 11:54 AM, Mark Phippard wrote:
On Tue, Jul 12, 2011 at 11:29 AM, Andy Singleton<a...@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
...
Mark, I agree with you that the existing merge will work better if we
apply some restrictions. I can see that the project is already going
that way, and maybe it is good to continue in that direction. As a
user, I would find that helpful.
However, we cannot get good results with the subtree merginfo format.
It is a failed architecture. A lot of smart people have worked on it,
and they have not achieved good results. It is the source of many
annoying problems. Even on this list, nobody defends it. They only
express a desire for "compatibility." You yourself have argued that
basically, it can't be done, that cyclic merge won't work. Yes, if you
stick with the subtree merginfo, IT CAN'T BE DONE. You are guaranteed
to be right. However, if we free ourselves from this one restriction,
we can do something good. I invite everyone to stop beating their heads
against this wall.
In my proposal, you can basically keep everything about Subversion the
same: the servers, most of the clients, the old merge command if you
choose to use it. It's all compatible. I am only asking you to give up
ONE THING: subtree merginfo. To succeed, we have to get rid of both
parts of it. We have to get rid of the subtree info, and we have to get
rid of the fussy little merginfo format. If newmerge is successful and
we want people to move to it, we can force the conversion by asking
"svn" to read the old merginfo and write some information into the new
format.
