A lot of what they're doing sounds quite similar to what we're working
on in our project. (Where we translates as the Stellation project, your
friendly competitors who used to be called Synedra, and before that
Coven. Yes, we've been renamed again. This time we went through the
legal process of formally clearing the name, so we're absolutely never
going to rename the project again. Really.)
And we are going to go open-source, probably sometime in February. (We'd
hoped to do it a lot earlier, but getting through the politics to get
permission to open took a lot longer than we'd expected.)
Anyway... The basic idea of lazy distributed branching, which is what it
sounds like Arch is trying to do, is something that Stellation will also
do. (And we have a spec written in Z that describes branching and
reconciliation.) It's a really useful, important notion. When you're
working on a big project, particularly with project-oriented versioning
(which we all - arch, Subversion, and Stellation are implementing in
some form), it's very difficult to properly coordinate work between
widely distributed people. Getting branching right is the first step,
but requiring a single global repository is still a serious problem.
Distributed repository replicas, with lazy branching and automated
reconciliation and merging makes a dramatic difference in how well the
system works. I'd strongly encourage you guys to take a look at the code
for Arch and Stellation (when we get it out), and put something like
that in to SubVersion.
I'll also take this opportunity to push one of my personal agendas... If
you're going to implement something like replication, take the time to
learn a specification language, and *write the spec*. Things like
replication/reconciliation are incredibly complicated, and it's really
easy to get things wrong. Without a really thorough understanding of
exactly what you want the system to do, you can't get it right; and with
something as complicated as replication/reconciliation, it's close to
impossible to be sure that you really do understand it unless you've
worked it through. For Stellation, I've got a specification of the base
system in Z (an excellent specification language for describing systems
that are predominantly transformation based). I've got a *partial* spec
of replication written, and I'm working on finishing it.
I know that proposing the idea of writing formal mathematical
specifications is not exactly a popular notion, but it really makes a
difference. The specifications that I wrote saved me *at least* three
months of work; quite possible a lot longer.
(For an example of the problems we saved... We're implemented using an
RDB (postgresql) for storage. Our original design was a multi-layer
filesystem. We were going to implement a simple filesystem using the
database. Then we were going to use the DBFS to implement a versioned
filesystem. Then we were going to build the real system over the version
filesystem. First, It turned out that the method we were planning on
using for mapping branches and merges onto the versioned filesystem was
wrong; second,we realized that the versioned filesystem model that we
were using would cause consistency errors when trying to merge certain
kinds of changes; and third, we were creating redundant data in the name
of doing good merges that made it *harder* to get merges correct.)
It would have taken months of effort to correct these problems after we
implemented them.
<MC>
On Sat, 2001-12-29 at 06:12, Branko Čibej wrote:
>
>
> -------- 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
--
Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
<mcc@watson.ibm.com>
*** The (recently renamed) Stellation project:
*** http://domino.research.ibm.com/synedra/synedra.nsf
*** GPG Public key available at keyserver.net
- application/pgp-signature attachment: stored
Received on Sat Oct 21 14:36:54 2006