>1) A global namespace is created for nodes in the revision graphs,
> or equivalently, their duals in the changeset graphs. This
> namespace is essential to maximum flexibility in tools
> which manipulate changesets: it allows them to refer to any
> and all changesets, regardless of how or where they are
> stored.
Subversion effectively has this, with repository revision
numbers and predecessors. A revision number represents an
entire revision graph, but also the change from its predecessor
(a known revision) to it. The extraction of the predecessor
revision is perhaps not as immediately straightforward as it
should be. And this doesn't really handle distributedness, at
all. But it's there.
So, you are saying that the "global name" of a revision is the URL of
the svn repository, the path, plus it's repository revision number?
Repository revision numbers in svn are global to the repository.
That presents a problem, as namespace design goes. In a typical shop
or developement effort, I'm likely to have several projects that are
related. If I store them all in one repository, then progress on just
one line of development in one project is not assigned sequential ids.
On the other hand, if I store each in its own repository, admin
complexity and costs and resource requirements goes up.
Queries to a repository can sort out the sequence of non-sequential
numbers for a particular project within a multi-project repository,
presumably, but that misses an important point of a global namespace:
that I should have a structured system of names (one isomorphic to the
structure of the development process) that is independent of storage
and access methods and that supports offline processing: a system of
names that reflects the semantics of the development process.
To be distributed, we'd simply need "revision@repository" to
represent a particular revision, and have revisions possibly
be successors to revisions in different repositories.
A global namespace should be orthogonal to storage. It should assign
names to tree states in a referentially transparent, global way,
independent of anyone's particular software tool product. That
facilitiates much, if you stop to think about it.
So much for the unique naming problem.
Please try to /think/ through the issues before issuing glib
dismissals. Nietzche said "It is not the least charm of an idea that
it may be refuted" -- but a glib dismissal is not a refutation.
> 4) The framework for changeset manipulation is made as
> orthogonal as practical to the framework for storage
> management. An abstraction barrier is maintained between
> merging tools and storage management.
This is an interesting choice. I submit that Subversion
should go in the other direction and make the framework for
changeset manipulation integrally tied up with the "SVN
filesystem".
Why exactly? So that nobody can use your changesets unless they
install svn?
> b) They have a very wide selection of storage management,
> indexing, and caching options available for the task
> of archiving the graphs ((A)).
Yes, it's essential for that. Can we live without that?
Probably.
Yes, I'm sure svn has the political and economic clout to make a big
mess.
> d) They should be designing systems in which changeset
> manipulation is handled by an open-ended, easily extensible
> framework ((D) and {*}).
Yes, it's very valuable, if not absolutely essential for this.
We don't need this, if what we're trying to do is replace CVS.
Admittedly, it's desirable.
Increasingly, I get the impression that "replace CVS" is
dev-list-speak for do-whatever-the-hell-is-most-convenient-for-us.
To avoid repeated merging,
There is no avoiding it in the real world.
But Subversion isn't designed as a changeset tool,
No, but elements of it are useful in that context. I think it would
be productive for the core developers to consider what it would take
to use svn as a changeset tool.
and it's never gonna be one;
Then you are willfully ignoring the _real_ source mgt. problems that
arise in modern software development.
I think there's a way to handle this...
A lot of issues worth dealing with in svn seem to get deferred from
the consideration they deserve by that vague assesment.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 14 01:58:21 2002