This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: source mgt. requirements solicitation



       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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]