> 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
Received on 2011-07-11 21:34:14 CEST