Post by Russ AllberyThankfully, 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.
Post by Russ AllberySo 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
--
Robert Collins <***@hp.com>
Distinguished Technologist
HP Converged Cloud
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/CAJ3HoZ3-9SMcqbvCkdt8bFMD0fiU+***@mail.gmail.com