[haiku-development] Re: Proposal: Moving away from Subversion
- From: Andreas Färber <andreas.faerber@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 4 Jul 2010 21:18:50 +0200
Am 29.06.2010 um 09:02 schrieb Niels Reedijk:
Debating every little detail about a tool really is the wrong way to
go. The question is not 'to which DVCS should we switch', it is which
decentralized workflow do we want to employ.
I disagree here. The question is not only which tool is most suited
for, say, Axel and Ingo. In that case we come to the conclusion that
only offline capabilities are needed and everything should remain
central.
The point Jack has raised is that the users, in our case the
contributors, and their workflows should be considered as well.
Which means in particular that the question of which VCS gives us the
best numerical compression ratio is pretty irrelevant since a Haiku
repository is simply much too big to allow contributors to push/
publish their repository on any decentralized free hosting site for
others to pull from. (Unless of course we start splitting the kernel
and the applications into their own repositories, which with the Jam
system in place is unlikely to happen.)
Therefore the only exchange medium is going to be text files or
emails. Maybe versioned text files but still text files. (And diff'ing
patches is plain ugly.) Settling for a DVCS would allow to exchange
the patch metadata but wouldn't change the workflow, and e.g. an mq
repository is not much different workflow-wise from a Quilt workflow
which again is independent of the VCS.
Assuming there's only one repository all of us can access, local
revision numbers / hashes are only of importance to the user itself,
so we'd just need to find a working number system for the central
repository.
Is there a pressing reason to abondon SVN as central storage? Sticking
with it would seem to allow the biggest choice of compatible DVCSs for
users and would avoid the numerical revision break hg would incur.
Where I do see room for improvements however is the SVN vendor
branches. Importing flat copies of, e.g., GCC makes us not only loose
their CVS history and diffing the branches slightly complicated / time-
consuming, there are no clear patch queues to review. I also fail to
see the necessity why virtually unmodified versions of dependencies
need to live in buildtools/vendor. Optional Packages are already
downloaded on demand, so we should be able to do the same for at least
some of the build tool dependencies. The current vendor branch
workflow leads to even simple and non-controversial changes not
getting upstreamed due to low visibility (I spotted two O_BINARY fixes
in binutils still missing in HEAD for instance that I plan to forward
to HaikuPorts-devs, given time). Vendor branches sort of force the
updating job on SVN committers.
The system I have been advocating over at HaikuPorts is to choose the
tool on a case by case basis, looking at what the upstreams use:
MPFR: SVN
MPC: SVN [for GCC 4.5+]
GMP: Mercurial
binutils: CVS
GCC: SVN
Autoconf: Git
Libtool: Git
Assuming that autoconf and libtool changes have been upstreamed
already and that those tool versions are only relevant on Haiku itself
(where users get binary Optional Packages instead; the
build_cross_tools_gcc4 script does not build them on another host), we
have one project using Mercurial and most others SVN or CVS, so we
could create a repository per project and choose the DVCS with the
best bridge support. Here the bridge tool suggested by Niels might
come handy.
Andreas
Other related posts:
