RE: On the Infinitude of Module Solutions.
From: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-05-17 23:27:44 CEST
No arguments from this end of the continent. I even expected you to say
Even though being able to have an actual tag concept tempts me greatly.
Keeper of the "A copy is not a branch" flame war,
---- Do you want a dangerous fugitive staying in your flat? No. Well, don't upset him and he'll be a nice fugitive staying in your flat. > -----Original Message----- > From: Karl Fogel [mailto:email@example.com] > Sent: Friday, May 17, 2002 1:52 PM > To: Bill Tutt > Cc: firstname.lastname@example.org; email@example.com > Subject: On the Infinitude of Module Solutions. > > 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: firstname.lastname@example.org > For additional commands, e-mail: email@example.com --------------------------------------------------------------------- To unsubscribe, e-mail: firstname.lastname@example.org For additional commands, e-mail: email@example.comReceived on Fri May 17 23:28:46 2002
This is an archived mail posted to the Subversion Dev mailing list.