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.