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

Re: general replies, last in thread?

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2002-02-06 17:26:02 CET

I feel kind of bad because Karl has asked us to take arch traffic off
the list, but I think this is mostly about revision control in general.
If there were an scm-hackers list I'd take it there. :)

On Wed, 2002-02-06 at 05:05, Tom Lord wrote:
> First question: should I start an scm-hackers@regexps.com list for
> general discussion about scm design issues? (reply off list please).

I'd probably join. It might not take off (it's always a little
difficult to build critical mass for a list which isn't related to a
particular product), but I've seen good results for things like gclist
in the past. (Yes, I'm not replying off-list, because I have a bunch of
other things to say.)

> A revision library is a collection of tree revisions with common
> files shared via hard links.

This is an interesting idea, but I find it a little disingenuous to use
revision libraries in your comparison with Subversion. It sounds to me
like revision libraries aren't an integral part of arch so much as this
cool thing you could do off to the side with almost any revision control
system, and arch happens to implement it.

For instance, when you say "Retrieving an individual file from a past
revision is essentially instantaneous," it sounds like you're talking
about the primary (diffy)

Also, for a huge project, a revision library may not be all that
space-efficient. The tree I work on has 72,904 files in it; at 1K per
inode (I don't actually know if that's right), that's 72MB per revision.

Revision libraries also won't work inside AFS, since AFS doesn't allow
hard links except within directories. (You're certainly allowed not to
care; just thought I'd mention it.)

> * Isn't Zack really neurotic about shell scripts?

I share his doubt. I see two issues with your approach:

  1. You require a lot from your base system, such that I think arch
only works out of the box right now on Linux-based and *BSD systems.
(You can get it to work on other Unix systems by installing a whole
bunch of gnu stuff.) This might limit arch's penetration.

  2. There is a lot of processing you can't do very easily in /bin/sh.
A shell script which starts out nice may become ugly if you have to
extend it to do "just one small thing" which doesn't easily fit into sh.

Yes, there are a lot of tasks, like boot-time startup, which fit well
into the /bin/sh mold. I'm not yet convinced that any significant part
of a revision control system is one of them.

> * On getting things "for free".

I agree with you on this point.

> Another problem is the whole question of mixed working directories.

They may not be very useful for a single, self-contained project like
gcc. On the other hand, for my primary use of revision control systems
(which is integrating a large number of packages, some written locally
and some written externally, into a unified system), you at least need
the ability to check out and operate on a small part of the project
instead of the whole thing.

---------------------------------------------------------------------
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.