On 7/12/2011 11:54 AM, Mark Phippard wrote:
> 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
> ...
>
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.
Received on 2011-07-12 18:17:12 CEST