-------- Original Message --------
Subject: Re: version control
Date: Thu, 27 Dec 2001 11:12:01 -0800 (PST)
From: Tom Lord <lord@emf.net>
To: gcc@gcc.gnu.org
I hope not to abuse gcc@gcc.gnu.org as a revision control discussion
list, but Florian's comment touches on an aspect of `arch' that
I thought a lot about GCC while writing. In other words, this feature
was designed partly in response to watching how CVS is used by GCC
developers:
Florian Weimer:
>Tom Lord <lord@emf.net> writes:
>> There are alternatives to Subversion [which also handle
>> file and directory renaming well]. See:
>>
>> http://www.regexps.com/super-secret/arch.html
>>
>> arch features distributed revision control (e.g. form
>> branches in your own private repository) and features
>> for merging that are fancier than what Subversion offers.
> Aegis offers something in this direction, too, although it lacks
> automation of repository synchronization.
arch doesn't "synchronize" repositories. Instead, there is a global
(worldwide) name-space of branches and revisions. Suppose that the
main-line of GCC development is in repository A. Any developer can create
a repository B and start a branch in B that just points to (not copies)
an ancestor from repository A. While working in B, you can update against
A, for example. From a user interface perspective, A and B appear to be
one big repository.
The existence of B imposes no administrative overhead on the owner of A.
The branching is symmetric: if B is made readable via FTP, users of A can
update against B, too.
If several developers do this in parallel, creating repositories, C, D,
E,...
all of those repositories support mutual branching and merging too.
I've also tried to make sure that the drudge-work of merging can be
farmed out and shared. A developer working on B can prepare (in B) the
merge of A and B in such a way that:
1. Whoever gets to review and commit changes from B to A
will have a clean (conflictless) merge. This isn't magic,
conflicts are conflicts, but the point is that the
activity of resolving conflicts can be neatly separated from the
activity of modifying the main branch.
2. The patch set for that merge comes in an easy-to-review
format (there's even a trivial but very handy web interface
for browsing the diffs between two revisions).
As I recall, Aegis' primary claim to fame is process automation: you
can define and impose check-in pre-conditions (e.g. that sources must
pass certain tests). arch doesn't directly provide that -- but such a
feature could easily be layered on top of arch (a few K of code).
arch's virtues for that purpose are (in theory) reliability and a nice
shell interface: repositories don't get stuck in states requiring someone
to fix them by hand; everything has a nice CLI with reasonable input
and output formats.
What I've thought might make sense is to (further) automate many of
the duties of the SC and release manager: (further) automate snapshot
and release cutting; automate distributed platform testing and
reporting; create a web-visible RC-driven queue of patches needing
approval; etc. Such automation looks simple to do, though getting the
details right for GCC would require some interaction with SC members
and other developers (and I am not entirely up-to-date in my knowledge
of where GCC process automation currently stands).
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:54 2006