Re: [Gnu-arch-users] [Fwd: SourceForge.net Service Update: CVS]

[Tom Lord]

    > From: Zack Brown <address@hidden>


    > Each project has its own set of goals, and those goals don't
    > overlap as much as you might think. So in practical terms,
    > there's no compelling reason why any of them should abandon what
    > their doing, in order to go do work on one of the others.

I think that what you're missing when you reach that conclusion is an
understanding of arch as separable components that can be described as
interoperability specifications and fundamental capabilities based on
top of them -- arch as generic architecture rather than specific
realization of that architecture.

Let me try to expain it this way:

Form in your mind an image of the "arch architecture" -- with the
primary components being:

* the global revision namespace
* the storage manager for archives
* the inventory mechanism
* mkpatch/dopatch
* the caching mechanisms
* the patch log format
* the project tree format
* the CLI

those pieces are layered in various ways but they interact in narrow
ways and are largely separable engineering problems.  The particular
realizations in arch itself (e.g., of the namespace) are something
that can be reasonably changed without having to throw away lots of
existing structure or code.  `tla' is _pretty_ clean in that regard --
and it's very, very tractable to make it moreso.

Now, let's suppose you have a problem you want to solve such as "Build
a revision control system with a recognizably CVS-like user interface;
with CVS-like access performance characteristics for file contents in
an arbitrary revision, ....etc."  Or, alternatively: "Build a system
that feels to users recognizably close to Bk".  Or, alternatively:
"add support for cryptographic signing of changes by authors and/or
use in access rights validation and content integrity".  Or,
alternatively: "add features to permit patch flow and merging in terms
of this-here changeset commutativity operator".

I claim that it is both practical and worthwhile to consider how to
solve each of those problems within the context of the arch
architecture (and, by extension, within the context of existing code).
Practical because each of them fits in to the architecture (and code)
in a reasonably clean way.  Worthwhile because, taking that approach
will have the result that the product system will have the sum of all
of those features.

When I look at something like, say, svn, through the goggles of the
arch architecture, I think that I break it down just a bit differently
from the way that they do.  They have some operationally useful
components -- but very "wrong" APIs between those components and
corresponding "abstraction leakages".  The clearest example is the svn
storage manager: conceptually a simple transactional file system with
inexpensive tree-cloning.  It's in the details, many of which are
there to solve problems that the arch architecture would locate
different, that I think the design starts to fall apart (e.g., the
global revision number; much of the meta-data components....).  In
practical terms, you could factor out work on such a storage manager,
simplify its interface, reduce the dependencies between it and other
parts of the revision control system, and nail it pretty well.
It'd solve a lot of labor and produce a better result, afaict.



    > So, all of this seems to add up to there being a different focus
    > in each project. SVN chases CVS; OpenCM chases their grand idea;
    > darcs chases its grand idea; and tla chases BitKeeper.

Although I read your reasoning up to that point of that conclusion, I
have no idea what that it is supposed to mean.

tla doesn't "chase BitKeeper" although for some project participants,
working on a free software alternative to BitKeeper is one source of
motivation.  That's true for Subversion, too, as far as I know.

OpenCM explicitly does _not_ chase a grand idea: it aims at a solid,
practically studied, and academically published exploration of a
handful of narrow ideas that arose out of the needs of Eros.

>From a technical point of view, I'm not sure that breaking down
projects into "chases BitKeeper" vs. "chases CVS" vs. "chases a grand
idea" is a helpfully useful distinction.  It seems to rely an
assumption that there is some important technical distinction implied
between these various non-technical goals -- I tend to disbelieve that
assumption.

The kind of "storyboarding" your doing here, making up a mythology of
these projects, seems arbitrary and potentially harmful.

-t