[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

general replies, last in thread?

From: Tom Lord <lord_at_regexps.com>
Date: 2002-02-06 11:05:04 CET

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

* 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

  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?


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.