[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: Mon, 11 Jul 2011 12:48:27 -0400

If you want to fix Subversion merge there are two issues that have to
be addressed. If you are not addressing these issues you are just
rearranging the deck chairs on the Titanic.

1. Cyclic merges (the reason we added --reintegrate).

http://subversion.tigris.org/issues/show_bug.cgi?id=2837

This is really a core design issue in SVN that is going to be hard to
work around. Kamesh explored some new merge algorithm ideas in:

http://subversion.tigris.org/issues/show_bug.cgi?id=2897

He may or may not have been on the right track. The solution is just
so complicated no one was able to really review it. Maybe a team of
two or three people (so there there is peer review) starting over with
the same basic idea could pull this off? This seems the only possible
way to solve this with our current design.

2. Subversion does not handle move/rename well (tree conflicts)

This is not just a merge issue, update/switch are also impacted by
this problem. I do not know what the current state of the art
thinking is on this problem. Can we auto-resolve tree conflicts at
some point? When this problem was first approached (before we came up
with tree conflicts) it hit a brick wall where it seemed a new
repository design was needed:

http://subversion.tigris.org/issues/show_bug.cgi?id=898

Fix these two problems without killing performance and we would have
solved the problem. The syntactic sugar type changes could come later
or on the side. But I see little real benefit in any of those
proposals without a plan and roadmap to address these two items.

Mark
Received on 2011-07-11 18:49:00 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.