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
arise.
- 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
Subversion.
Best,
-K
