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
Received on 2011-07-11 22:56:04 CEST