First question: should I start an scm-hackers@regexps.com list for
general discussion about scm design issues? (reply off list please).
* What's a Revision Library?
A revision library is a collection of tree revisions with common
files shared via hard links. Having a revision library means that
you can do all kinds of things like index all your past revisions
using agrep, browse them with dired, compute arbitrary diffs
quickly, etc. While, officially, I hate to admit it -- I'd bet that
revision libraries are a feature that could be easily added to
Subversion.
* Aren't your comparison documents slanted towards arch?
Sure. It isn't supposed to be a 3rd party review. It's supposed to
explain why arch exists in spite of Subversion (and CVS). Make a
complementary document and if it's good, I'll link to it.
* What's better: file systems or databases?
Let's take it to scm-hackers, if that list comes into being.
* Isn't Zack really neurotic about shell scripts?
Yup, he sure is. The shell is far from perfect, but Zack is
over-reacting. Consider all the booting and sysadmin infrastructure
on every unix-ish box (built from shell scripts). Consider how GCC,
to which Zack contributes heavily, is configured and built.
Consider the once extremely popular MH mail handling system.
Consider the history of CVS. I'm sure the list could go on...
/bin/sh provides a compact and reasonably portable notation for
composing the basic shell utils. It resembles functional
programming in some (useful) ways. If you don't believe it has a
future, investigate "recent" developments such as SCSH. Shell
programming is a fundamental breakthrough -- a very large part of
the reason so many of you are using unix-ish systems at all.
Sheesh, Zack, don't let the prevelence of crappy shell scripts in
the world put you off the concept entirely. (That said, I'm
sympathetic to Zack's anti-shell heuristic.)
* On getting things "for free".
So, BDB gets you (low level) transactions "for free" and WebDAV gets
you browsers "for free". But BDB has administrative costs and
WebDAV has API and administrative costs. If there's a general
design pattern here, it might be revealed by considering the very
early history of unix file system design. Unix went up against
contemporary systems that had structured files, giving users lots of
"features" related to those structures "for free": but the
complexity of those structured file systems was blown away by the
very simple semantics of unix files and the consequent general
applicability of unix shell utilities. Structured files at the OS
level were a false economy, and so too may be forsaking simple file
system uses and established protocols for databases and the latest
reams of specs from W3C.
* Does arch store diffs on the server?
Yup. Think of two layers: One provides the bare essentials for
distributed repositories. The second provides all kinds of
additional (disk resident) data structures for convenience.
After getting the structures for distributed repositories right, the
rest just falls into place.
* What do you *really* think, Tom?
One problem that I perceive in the design of Subversion is that,
very late in the game, you're wondering about the semantics of
branches and merging -- by contrast, arch starts from clear answers
to those questions, then asks "how do you package this into a usable
system?"
Another problem is the whole question of mixed working directories.
That goal follows from trying to emulate the CVS user interface, and
just as well as anyone, I can make up scenarios for how it can be
used, but truly, it seems to me like a crazy feature that just
invites programmers to make revision-control-mediated mistakes.
Thinking in terms of coherent whole-tree patch sets is, in my
opinion, where programmers should be. Having worked that way for a
while now, I'm happy to report that its fun, easy, and improves the
payoffs from one's efforts. A little discipline goes a long way.
Another problem is all the dependencies or semi-dependencies on
other software, from BDB to apache to WebDAV...I think you're
working much to hard to achieve your goals and using way too many
lines of code. You are, however, very far from alone in that
mistake and, paradoxically, that might make it not a mistake after
all, in some sense.
So, I'm not so sure Subversion is the best choice for programmers:
distributed repostories and fancy merging are too critical. On the
other hand, I wonder if svn has applications for business-oriented
groupware. I'm not sure that it does, but I can see a case for it.
What I have in mind is the idea that users won't run a subversion
client themselves, but rather access an ASP that runs one on their
behalf. Make sense?
Regards,
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:04 2006