Tom Lord <lord@regexps.com> writes:
> One of the (unstated?) goals in Subversion was to keep the
> server's semantics very simple, and push as much as possible
> into the clients.
>
> Very close to that idea, and, imo a better idea, is to not only keep
> the server semantics simple, but also to make a very simple client
> (both interactive and, in multiple ways, programmatic). Then strictly
> layer the "CVS replacement" UI (whatever that means) over that.
[I have the feeling that if it were not so late, I wouldn't have
written so much here. I hope it is coherent.]
I think you're getting at "hackability". I really hope Subversion is
hackable.
I usually get funny looks when I say that how easy something is to
explain --- and I mean, explain well enough that your listener can go
start using the thing --- should be a primary concern. Generally,
folks are happy to handle each problem by adding a new wrinkle,
introducing a new concept to the API, but over time, I believe those
wrinkles increase the initial investment of mind needed to use the
thing to the point where the project just isn't as exciting any more
to the hacking public. They raise the hacktivation energy needed.
You've really got to have a few simple concepts that get you almost
all the way there, because you can't afford more than that before you
start losing people.
This is one of the reasons I like Greg Hudson's protocol so much more
than DAV. When I read the DAV specs, my eyes glaze over faster than
donuts in a Krispy Kreme factory. No offense meant to the amazing
contributions Greg Stein has made to Subversion (I usually keep my
reservations about DAV to myself in appreciation of his efforts), but
he has just never seen DAV's complexity as much of a problem.
In contrast, I'll predict that, because anyone can look at a trace of
Greg Hudson's protocol and start writing their own thing that speaks
it just fine, anyone will, and you'll see a ton of interesting stuff
come out of that. (I guess the mindshare DAV holds will ensure
interesting stuff on that front, too. Subversion benefits either
way.)
The filesystem does have a well-defined interface and semantics all by
itself, in the absence of any network protocol, working copies,
etc. at all. This was to help people write other tools that work on
Subversion filesystems.
And generally structuring Subversion as a bunch of libraries was, at
least in part, another attempt to increase its hackability: since
there are a bunch of internal interfaces designed carefully enough
that one can learn and use them, people have a lot more options for
where to plug new and weird stuff in. If you understand Subversion's
'editors', you can go a long way.
Sure, some of those interfaces still have only one client, so they may
have gotten all wrinkly and incestuous. But the principle is
certainly there.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 14 09:05:37 2002