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

Re: The `on_disk' and `in_repos' templates.

From: Greg Stein <gstein_at_lyra.org>
Date: 2003-04-09 00:44:12 CEST

On Tue, Apr 08, 2003 at 01:43:54PM -0700, Jay 'Whip' Grizzard wrote:
> My $0.02. I really don't have a right to an opinion here, so take with a
> large grain of salt. :>

Hell yah, you have an opinion. Everybody does. We'd be idiots not to listen
to users of the system.

Don't erroneously align the notions "allowed to have an opinion" and
"allowed to commit" :-) Just because people don't have commit doesn't mean
they should sit meekly on the sidelines.

> If most people are going to call svnadmin-create-template-wrapper most of
> the time they create a repository -- why the heck should the functionality
> be in a wrapper? At that point, it seems like a pretty core part of the
> functionality of the system!

Exactly my reasoning. Thanks for stating it so much more clearly.

> ... now, I'm going to go out on a limb here and add this: Not only do I think
> that the in-repos-template stuff should be a part of svnadmin -- But I think
> that it should be enabled (with a simple, standard template) _by default_.

I'm fine with this, but deferred it until after the feature was coded.

> Face it, subversion is quite hard to understand at first glance, for a lot
> of people (especially those who's primary history is with CVS), so even
> shrugging off usability issues with "Well, it'll be in the manual" isn't
> a good solution.

I tend to agree. And despite what it sounds like, I'm sure that Karl and
Ben, et all would also agree. "It should just work [as you expect it]" has
been the design for a lot of the command line interface, for example.

> Recently, a lot of the messages I've seen (on these topics, specifically,
> but on others as well) have been of the opinion (roughly) that "if someone
> doesn't want to take the time to read and understand the entire manual,
> they don't deserve to get benefits from our tool". Nobody has voiced anything
> quite that directly, but that's the jist of things (think of the
> 'administrators should have to spend time to understand bdb and how to
> maintain the repositories to keep the size of the database from
> spiralling out of control' discussion).

It's a tough question. I agree that it should "just work", but [in the
concrete example] that is also balanced by "we don't want to kill the
ability to restore a corrupted repository".

I'm also generally of the opinion that an administrator *does* need to know
about the care and feeding of the systems they are running. It is our job to
make it as simple as possible for them, and as invisible and
self-maintaining as possible, but where we can't... they should know.

> [Example... another quick survey: Who here -genuinely- feels that putting
> 'db_archive | xargs rm' in the default post-commit hook (not even
> post-commit.tmpl) wouldn't be an acceptable, or even good solution for
> 99% of the future userbase?]

Personally, I agree with this. Altho I'd implement it directly in the
svn_repos or svn_fs libraries (there is a db_archive function that can be


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 9 00:40:44 2003

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.