On 17 April 2015 at 18:13, Russ Allbery <r...@debian.org> wrote: > Marc Haber <mh+debian-de...@zugschlus.de> writes: > >> Thankfully, git is by far the best VCS on the market and the vast >> majority of people seem to agree. But imagine the outcry if ten years >> ago Sourceforge had said "our VCS is svn and we don't support anything >> else". > > Er, they did, didn't they? I could have sworn that they only supported > CVS initially, and then only added Subversion, and getting Git support > took forever. > > Launchpad, similarly, is probably suffering a lot from the decision to > only support bzr. (It suffers from some other things as well, such as > asset licensing and how difficult it is to stand up your own, but I think > the VCS is a major problem right now.)
https://dev.launchpad.net/Code/Git - git support is there in nascent form now and under active development. I think a couple of months will see it looking pretty solid. > So you're of course right -- there's a tradeoff. > > However, I still stand by the decision to only support a single VCS, at > least when you start, because you can move a lot faster and implement a > lot more functionality that people care a great deal about. If you can > find the right VCS to use that 90% of people are content with (and I think > Sourceforge started there), I think your resources are much better put > into adding other features than adding more VCS support. > > I have no interest in ever using bzr again, but I strongly suspect > Launchpad got a lot farther and does a lot more because the choice was > made to only support bzr. Now, of course, they need to switch to Git, or > at least support it, and that's going to be a ton of work, but I suspect > the order in which they did that made for a better system in the long run > than if they'd tried to support both bzar and Git (and Mercurial and the > other ones that were looking viable) at the start. When Launchpad started before bzr or git or hg existed - back in 2004 - we started with arch. When we started bzr as a project, (again, before git or hg :)) we were doing it with lessons-learnt from arch, and a clear picture about what we'd need from the web site. Our intention then was to use repository conversions to get content into Launchpad, rather than being polyglot - because polyglot implies a raft of tradeoffs. In hindsight, what that strategy actually did was make high fidelity incremental imports a key success factor, and that has itself a raft of tradeoffs - so we spent a huge chunk of effort on that (and its there and working) - but I think now that taking a federated approach for the non-hosting needs (read from X systems directly for building etc) would have been a lot faster to deliver, and would have allowed more of the VCS work to focus on hosting needs rather than conversion needs - conversions could be scaled out amongst users wanting to use the platform, rather than the platforms developers. OTOH a chunk of the planned features around VCS driven builds were tightly coupled on understanding branches within the VCS and triggers on changes etc - but all of those could have been only supplied for hosted branches, with a low code complexity cost. Actively supporting hosting of multiple VCSs would have been a huge distraction in 2005 when the explosion happened. Supporting a VCS for hosting isn't as simple as just parsing the output of $tool log. Users need support. They need documentation and assistance. Creating repositories needs to ask what VCS type to use in addition to any other questions needed, all such questions tend to decrease the % of users that get through the become-a-user funnel. You need backup glue that works with [whatever] mechanism the VCS has to deliver atomic commits. You need a scale-out strategy that is suitable for the VCS in question. You need a user model that works for that VCS (and some are radically different to others) - darcs was very visible at the time we started, for one of the most different-to-mainline-VCS models. Lastly at that stage LP was not yet open source, so it simply wasn't possible for possible users to scratch their own itch and submit patches - and thus when assessing strategy we assumed we'd have to write everything, so supporting two systems really need to get twice as much utility for Ubuntu developers (the primary audience then) - but Ubuntu had already decided to standardise on a single VCS, as part of the basic design of the tooling, there was no expectation of increased utility. -Rob > -- > Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/871tjj5lle....@hope.eyrie.org > -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj3hoz3-9smcqbvckdt8bfmd0fiu+7hcnwsp3fmwxujrbjn...@mail.gmail.com