On 2/3/14, 6:22 PM, Paul Hammant wrote:
> I've been nudged by nice people to post this here - honest !!
>
> 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 :)
Don't see it happening.
In essence your argument here is that the Subversion code base can't get us
where we need to go so we need to use the Mercurial code base to get us there
and apply the Subversion name to it in order to leverage that brand.
Your argument presupposes that where we need to go is to become a distributed
version control system. While distributed systems are very nice in some
situations, particularly for open source, I don't think they are the best
system for every situation. They add complexity to gain features that not
everyone needs or wants.
If we wanted to be a distributed version control system we could have made that
decision to head that direction. In fact we publicly said we would not to go
down that road almost 4 years ago:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201004.mbox/%3C4BB60D1E.9030202%40collab.net%3E
I have a hard time accepting that the Subversion brand applied to a version of
Mercurial helps much with uptake. Mercurial itself does not have a bad brand
and should be helped greatly by Facebook switching. Nor do I think Mercurial
renamed to Subversion gets a pass on acceptance in businesses. Based on my
experience, I've seen a very slow upgrade cycle for businesses between
Subversion versions. This is despite our newer versions providing significant
improvements. People are very cautious about upgrading. I find this odd given
that we have very strong compatibility guarantees, but it is the reality.
Despite 1.6.x not being supported I'd bet that this is our most widely deployed
version at current (with 1.7.x deployments becoming more common through this year).
As you point out in your blog, Subversion almost certainly is not leaving the
ASF. Which means Mercurial would have to join the ASF. What you may not be
aware of is the licensing consequences. Subversion is under the Apache License
v2 (as of 1.7.x which is our first minor release after joining the ASF, before
that we were under Apache License v1). Mercurial is under GPLv2. A
requirement of bringing in code into the ASF is that it be switched to the
Apache License v2. So not only would the Mercurial people want to join the
ASF, they'd also have to be willing to change licenses and they'd have to go
through the process of doing so (which might be non-trivial depending on how
they've been handling their licensing). If you can't do that then you don't
have a base of code to work on under your plan and you're starting over from
scratch.
I think your examples of reverse takeovers have some different properties than
a version control system does. Testing/Development frameworks don't have to be
nearly as backwards compatible as a version control system. It's very easy to
make changes and then cut over. You continue using the old version with your
old code after you cut over. You can easily cut over project by project, on
the time frame that each project can deal with. But you can't necessarily
easily cut over a version control system like this. You have to migrate your
repository, switch clients, replace all the integrations (IDE, build,
notifications, etc...). If your using one large repository, that means
everyone has to migrate at the same time. You could of course avoid that by
supporting bi-directional compatibility. That is no easy task. If it was an
easy task every developer would be able to use whatever version control system
they wanted with whatever central repository was being used. However, I'm sure
you're aware of how difficult that actually is in practice.
In the end I suspect you'd end up killing both projects as you'd stop almost
all forward progress on both sides while we sort through all of that.
Received on 2014-02-04 05:23:35 CET