The important question is, are we making any decisions now that
irrevocably harm our ability to implement first class change
history later?
My hunch is that we're not, but if anyone (Tom? Brane?) sees a
place where we *are*, that would be very important news right
now.
First, I don't think that's quite the right question to ask.
Second, I don't think that's the right way to ask me the question.
So lemme explain those answers:
We're all loosely supposing a kind of lattice, here.
ULT
^ / | \
| / | \
|
1.0ALT .... 1.0PLN
t
i | | |
m
e ........
| \ | /
|
CUR
<-- alternative developement paths -->
All the elements in this lattice are source projects and unions of source
projects.
"CUR" can be read as "the current state of svn", or "the current
state of arch" or "the current state of svn, arch, and possibly other
projects", etc.
"ULT" can be read as "the ultimate, wonderful supercool collection of
source management tools, sufficiently done, stable, deployed and
supported that we've all gone on to work on something else".
"1.0PLN" is an element that includes, say, svn 1.0 as you're currently
planning for it.
"1.0ALT" is some alternative intermediate milestone. Maybe my
suggestion to focus on storage mangement. Maybe something else
entirely.
So, one good question to ask (not that it's easy to answer) is about
the cost in money and labor to get from CUR to ULT by various paths.
Even if work you do to reach 1.0PLN is "revocable", that doesn't mean
that other paths from CUR to ULT aren't significantly more efficient.
Another good question to ask is what value various internal elements
in that lattice have as intermediate releases. This is another hard
question, in part because you have to take into account the money and
labor of third parties. The transition from 1.0PLN to ULT may impose
significantly different costs on users than the path from 1.0ALT to
ULT. And there's ego costs and project momentum costs, too -- lots of
squishy "human factors" to consider.
Does taking one path vs. another impose "irrevocable harm". Yes and
no. No, no irrevocable harm, because, heck, it all converges on ULT,
right? But also: Yes, it can cause irrevocable harm, because, hey,
traversing the edges in the graph of the lattice aren't free to the
sponsors, the volunteers, or the users -- and different paths may very
well have very different costs. Really terrible paths may even have
costs so high that ULT is either never reached or never adopted.
There are many problem domains where you can't be sure in advance what
ULT is. There are many problem domains where you can't even be sure
in advance that ULT exists. Superstitious belief in an ULT, or an
overly-ambitious choice of ULT are fauilure modes to be avoided. And
no matter what, even where there is a clear ULT, there's almost
certain to be at least a little bit of arbitrary choice about what ULT
is.
What about the domain of revision control? I think a practical ULT
exists. I think that ULT isn't terribly arbitrary. I've been trying
to send you, gcc-list, arch-dev, and anyone who will listen snapshots
of various reasons why I think this is so and, at least in outline,
what important properties I think ULT has.
As you may have read, I think the right way to deal with the
complexities of analyzing that lattice is to gather a group, and spend
a few weeks or months identifying ULT, formally specifying its
critical components, and then nailing its implementation cold. If
you've followed the arch-dev lists carefully, you've read lots of
details about that. If you followed the recent gcc list in that
light, you can see some of the practical implications of the approach
I'm advocating as it relates to the needs of big, complicated,
distributed, projects.
Having said all that abstract stuff, yeah -- every week or so some
detail goes by on the svn dev list that strikes me as _wrong_, or at
least highly dubious. Recent examples include (a) some casual
toss-offs about storing history (for merge purposes) in properties,
(b) a feature request that was interpreted to imply the need for
access lists for file properties, and (c) the long discussion about
"binary" file properties. Less recently, and in order to mention some
examples that aren't about file properties: (d) a lot of the details
about "mixed version working directories" has struck me as confused
and diversionary, (e) the way you handle tree rearrangements and svn
"metadata" in working directories seems needlessly complicated.
Finally, (f) when you add up all these details that seem to me to be
broken, and then deploy them, I think adopters will wind up investing
in processes and computing system infrastructure that are not
compatible with ULT -- those adopters will either get stuck there, or
have to pay a steep cost as improvements proceed. Lots of little
stuff like that, combined with the brownian-motion hill-climbing
approach that svn has largely taken -- yeah, I think that, in some
sense, irrevocable harm is being done.
A few months ago, I suggested a "stop and rethink" phase. _Maybe_
this has helped to explain why. I didn't intend to _prove_ anything
with this message -- just to help you read a lot of older stuff in a
better light, so that you can maybe begin to see what I'm seeing for
yourself.
Now, the second point: I don't think that's the right way to ask me
the question.
As you've probably read, I'm unemployed, financially screwed, and blah
blah blah. Let's see -- today I got my, hmm, I think third notice of
a credit card being canceled with full payment demanded in 15 days,
etc. You know who's more obnoxious than telemarketers? Credit
collection services. It's like a goddamn wake-up-call service.
That's not entirely anybody's fault [*] -- but, uh, in addition to
sending you and others lots of good information about the design space
and so forth, you might have noticed me asking for a little
solidarity, here.
So, at this very late date for me, when some rather severe financial
problems could have gracefully avoided just a few months back, while
I'm wondering about the best strategy to pack my pantry before the
last card is turned off, to _finally_ get a direct request for help
with svn from an @collab.net address -- well, lemme just say that it
makes me want to reiterate my request for a little solidarity here.
"I don't volunteer for anything in the free software world anymore."
-t
[*]: Well, actually it's a little bit more complicated than that --
but in this public forum, for the sake of conversation, let's adopt
that polite fiction.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 12 09:05:02 2002