I've renamed this thread; it had been "Re: svn commit: rev 1957 -
trunk/subversion/include trunk/subversion/libsvn_wc", which wasn't
exactly eye-catching :-).
I'd like to propose a way out of our module system dilemma. Right
now, the two horns of the dilemma are:
1) Write a description-based module system, where a description
file (or property, whatever) provides a list of external
"things" that are included in the module. Checking out the
description results in the external things being checked out
too; updates and commits account for them, insert hand-waving
here, to be supplemented by concrete description below.
...OR...
2) Make a first-class "reference node" type, recognized by both
filesystem and client, that points to external things. When you
check out a reference, it drags in the thing it points to, while
still remaining aware that its a reference (so that if the
reference changes, all the appropriate changes are made).
Updates and commits account for them. Insert hand-waving here,
to be supplemented by more hand-waving below.
These two solutions are not mutually exclusive. There's no reason we
couldn't implement both, except that it might cause some confusion for
users who have to decide which way to do a module.
The reference node solution has a certain geek-elegance appeal. I
find myself instantly attracted to it. It's simple to explain the
concept, and it's easy to see, at a high level, *how* to do almost
anything one might want to do with modules via this method. Indeed, I
must say outright that I favor the reference solution hands-down.
So why am I about to start on solution number 1? :-)
A few reasons. First, the simplicity of references is deceptive.
They are conceptually easy, yes, but good concrete interfaces are
actually hard to come up with. One always has to distinguish between
acting on the reference versus acting on the thing it refers to, and
its easy to end up with inconsistent situations (especially at
reference creation time, and reference changing time). Here I'm going
to hand-wave a bit, because I don't have time to write up examples of
all these situations. But you can come up with the problems yourself
pretty easily. The recipe is simple: first come up with what *seems*
like a good interface for reference creation and modification, and
then try to think of situations where it breaks down. You'll find
they're very easy to imagine :-). (Unfortunately, not all of the
discussion about this has happened on the list; some has been on IRC,
some has been on phone calls. So these objections might look like
they're coming out of the blue sky, when in fact they're products of
discussion with others.)
A second reason: references involve changes to both server and client
side. Creating a new node type involves lots of little changes all
over the code. Not a showstopper, just very time-consuming.
Finally, I find that when I talk to people about how modules will be
used, I get (roughly speaking) more different answers than there are
particles in the universe. So I don't think that we're going to fully
nail this the first time, whether we use references or descriptions.
Given that, I want to start with descriptions, since they're easier to
implement, and have much less drastic repercussions on the rest of
Subversion.
Think of solution (1) as training wheels for solution (2). I don't
believe we can do a good job of (2) in a schedulable way, because it
involves huge unresolved questions about both interfaces and
semantics. Those questions will be partially resolved through
discussion and thought, and partly through experience -- experience
which using (1) can help us acquire. In the meantime, (1) gives us a
useable module system, perhas one that will (in practice) suffice for
most purposes.
I honestly don't know whether (1) will end up being throwaway code
someday. If references eventually turn out to be everything we could
hope for, then it will. But that's not at all a sure thing. I think
there's a possibility that (1) will turn out to satisfy most needs.
Please remember that this is *not* a vote against references. Anyone
who wants to start work on a reference node system right now should do
so. There's no reason the two can't develop in parallel. But I
personally am not planning to devote coding time to it before Alpha
(and therefore not before 1.0). It needs a LOT more discussion and
design cycles... And in the meantime, we need some sort of module
solution.
Here is some more detail about (1):
It's basically what's described in issue #517, except Mike Pilato
suggested the following modification: instead of a file, have a
svn:references
(or "svn:external-sources" or whatever) property that can be put on a
directory. The value of the property is a description of additional
items to be checked out into subdirectories (the format of the
description is the same as the file format described in issue #517).
So during a checkout, if you encounter this property set on directory
"A/", then each item listed in the property's value will be checked
out as a disconnected subdir of A/.
Here, "disconnected" means that the subdirs do not get entries in
"A/.svn/entries". They're simply there. Whether commits and updates
recurse into such subdirs is something we can decide (maybe
conditionally, if they're listed in the property). When the property
changes, the subdirs change too (though paths to local mods remain, as
per usual). We can either interpret the property at propset time, or
(better) at update time, with commits blocking until the property has
been interpreted.
(This is still not as concrete a description as I would like, but
there are physical barriers to how much writing one can do in a day
:-) .)
Anyway. This supports multiple-repository modules (something that I
think *is* going to be important right away) simply. It adds no new
node types to Subversion. It doesn't affect the server code. It's
easy to implement and gets us useful functionality right away.
I've always been a little wary of the "worse is better" philosophy,
but this is one case where I think it will help us to do the worse
thing first. References might be super-elegant, but there's just no
way we can have them done by Alpha without sacrificing either time or
design quality.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 17 22:54:23 2002