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

Re: Subversion should merge with Mercurial (reverse takeover)

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Mon, 03 Feb 2014 22:09:41 -0600

Paul Hammant wrote:
> http://paulhammant.com/2014/02/03/facebook-scaling-mercurial-for-trunk-based-development
> -
> (scroll down half way).
> I'm a user of Subversion from about 0.7 onwards (via Codehaus). I was at
> the 1.0 party in Brisbane, CA many tears ago. Like Perforce, Svn is still
> out in front *for a couple of features*. One that is fascinating for me is
> composite checkout (sparse directories for you, client spec for Perforce).
> Google uses the hell out of
> that<http://paulhammant.com/2014/01/06/googlers-subset-their-trunk/>,
> but Facebook don't. I compared the two companies a few weeks
> ago<http://paulhammant.com/2014/01/08/googles-vs-facebooks-trunk-based-development/>.
> Mercurial does not have a sparse-direcories feature that you could use to
> simulate a composite checkout. Not does it have, by default, fine grained
> permission on directories (incl branches). Thus, if y'all were to consider
> a merger of sorts, Mercurial does not yet have a superset of Svn features.
> Discuss :)

I promised Paul I'd follow up here with some thoughts I'd already sent
him privately :-).

It's a very interesting idea. But fundamentally I think some of
Subversion's best strengths come from its being a centralized system:

    - Editable log messages, editable revprop metadata.

      (This has really saved me a few times.)

    - True partial checkouts.

      This doesn't formally depend on centralized VC, but is much easier
      to implement in a centralized system -- fewer thorny questions

    - Serious access control ability, tuned to enterprise development.

      (E.g., invisible/absent dirs, log message protection, etc.)

      This is huge, and Subversion has rocked pretty hard in this area
      for a while. Though I don't know how git submodules are doing
      lately, nor if hg has an equivalent. Maybe this advantage isn't
      such an advantage anymore?

    - Conceptual model is simple and easy to explain.

      Lower cognitive load on users can be a big deal. Not all users
      live and breathe version control; for those who don't,
      decentralized systems are inevitably harder.

    - Repository-wide policy is possible.

      Meaning that some problems can be caught earlier in development.
      IOW, centralization is sometimes what you want.

None of the above is to say that one way is "better". Decentralized
version control is great, and is definitely the right model for many
situations. But there are certain situations in which Subversion is the
better choice, and I'm not sure how that property could be preserved if
it were to merge with Mercurial via a reverse takeover. Mercurial is
much more like Git or any other decentralized system than it is like

Received on 2014-02-04 05:10:22 CET

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.