This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: source mgt. requirements solicitation
- From: Tom Lord <lord at emf dot net>
- To: gcc at gcc dot gnu dot org
- Cc: torvalds at transmeta dot com
- Date: Sat, 14 Dec 2002 13:43:48 -0800 (PST)
- Subject: Re: source mgt. requirements solicitation
- References: <200212142107.gBEL78R23083@deepthought.transmeta.com>
The OpenCM project seems to still believe that distribution is
just about "disconnected commits" rather than understanding
that if you do distributed repositories right you shouldn't
have branches at all (instead of a branch, you should just have
a _different_ repository),
Branches can span repository boundaries just fine, and that's a nice
way to keep useful track of the history that relates the two forks.
Distribution is orthogonal to branching. Two repositories can be
separately administered and fully severable, yet branches can usefully
exist between them. For the "branched from" repository, this is a
passive, read-only operation.
Looking at the current projects out there, the only one that
looks like it has more than half a clue is "OpenCM". It
doesn't seem to really do the distributed thing right, but at
least from what I've seen it looks like they have the right
notions about doing it.
What aspect of arch has you confused? or, alternatively, what flaw
do you see in arch's approach to distribution?
The _real_ issue about independent repositories is that it
makes it possible to do truly independent development, and
makes notions like branches such an outdated idea.
Arranging that one line is a branch of another (even when they are in
two independent, severable repositories) facilitates simpler and more
accurate queries about how their histories relate. Among other
things, such queries can (a) take more of the drudgery out of some
common merging tasks, (b) better facilitate process automation when
the forks are, in fact, contributing to a common line of development.
GCC development faces a problem which Linux kernel development, you
seem to have said elsewhere, avoids by social means: it has direct and
appreciated contributors to the mainline who, nevertheless, are asked
to contribute their changes indirectly through a formal review and
testing process (rather than through, say, a "trusted lieutenant" --
in other words, in GCC, the work pool of the "lieutenants"
("maintainers", actually) is collected and shared among them in
flexible, fine-grained ways that are performed with considerable
discipline). Distribution _with_ branches can be a boon to those
contributors and the maintainers.
Overall -- I don't think there can be _that_ much contrast between the
GCC and LK development processes. GCC is a bit like LK, except that
instead of a Linus, GCC has a team. That team needs (and has) tools
to make them effective as the "virtual linus". (Some of us have ideas
for even better tools :-) That there is less of a tendancy for 3rd
parties to throw up their arms and make their own forks may not have
quite the implications you assert: the natures of the two systems and
the uses they are put to make comparison very difficult.
-t