[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: It's time to fix Subversion Merge

From: Mark Phippard <markphip_at_gmail.com>
Date: Tue, 12 Jul 2011 12:25:37 -0400

On Tue, Jul 12, 2011 at 12:16 PM, Andy Singleton <andy_at_assembla.com> wrote:

> 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.

I really do not know if I agree with this, and I think you might be
being a bit naive if you think that simply by creating a new format
you are going to not have problems and you are going to even create an
improvement. That said, I think some of the ideas around storing
patches is at least interesting.

I actually do not think mergeinfo is our problem or even our limiter.
I agree it would have been easier to implement if we did not support
all the odd cases we do, but at the same time, I think all of those
odd cases are working pretty well now. So at best, removing support
for that stuff might just make future work a bit easier.

The problem in merge is in core SVN. Merge tracking was always based
on the premise that merge in SVN worked fine, but it was annoying to
have to manually track merges and specify the revisions to merge. So
merge tracking tracks that and allows the simple merge syntax you are
advocating. In that sense, merge tracking accomplished its goal and
as of 1.7 the last of the warts in the implementation should be
resolved.

The problem is that SVN merge does not really work fine. The design
of SVN makes cyclic merges really difficult and perhaps impossible.
The lack of support for moves and renames makes merge not useful for
people that refactor a lot etc. None of these are problems with merge
tracking.

You seem to want to extend merge tracking to provide new ways to solve
these problems. Great, design it and propose it. I do not
necessarily see why that info cannot be stores in properties, or even
the existing property. Nor do I see why we cannot migrate the info we
have to a new format. We need real design to have something to
discuss.

Finally, in your new design do not forget about things like log -g and
blame -g, as well as the mergeinfo command. These features are all
necessary parts of a merge tracking plan and must have answers from
the first release.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-07-12 18:26:10 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.