On 7/11/2011 3:33 PM, Bob Archer wrote:
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.
Well, subversion was a better CVS, perhaps it is time for svn.Next to be a new
subversion. It seems like the discussion on merge always comes with the baggage
of the underlying design. I think the same issue occurred with CVS... it was
just too much to retro fit.
git is fine and all, but it is hard to get corporate buying... svn with a
central repo that allows authorization and server side hooks and stuff is quite
important there. It also seems that many people want offline commits and
private repos too. However, svn.next could probably learn much from git and
mecurial. It seems people don't have a problem with opinionated software if it
is fast and works.
BOb
If you want offline commit and private repositories, you can use git or
mercurial. We use both of them at Assembla. Subversion with those
features would not add much because it would look like a variant of
mercurial. It would lose one big advantage of subversion, which is
simplicity for the user. It would load the client up with new commands
and mental models to move changes between the client repository and the
server repository, and maintain local repositories.
I am proposing to preserve Subversion as a completely different kind of
beast. People seem to like it, because it is simple to use (checkout,
update, commit, and it looks like a filesystem), and it supports big
consolidated central repositories and big files, and you only need the
working copy locally. I am proposing to keep the server and central
repository unchanged, and just make smarter clients.
This philosophy can be described as "dumb server, smart client". You
use the server, with the existing behavior, to keep revisions and serve
up some patches. Then you make clients that are smart enough to do
things like merges, and save their own data structures in the
revisions. You can also add Web apps that do things like cloning and
log/blame change reporting. This preserves subversion as something
unique, and it gives you an evolutionary path (just add clients) that is
faster and less ponderous than revising all servers, and with them, all
clients. Using this philosophy, we can improve svn merge enough to
enable some new, modern workflows.
Some of my suggestions come directly from this philosophy.
* Keeping merge_history as a normal file that servers and other clients
do not need to understand. We just use the server to update it
incrementally.
* Handling file moves on the client side with pattern recognition and
memory. We don't try to fix the server side "copy + delete" operation.
* Adding a "clone" and foreign merge operations in Web applications and
clients that work with existing svn server software.
--
Andy Singleton
