My $0.02. I really don't have a right to an opinion here, so take with a
large grain of salt. :>
> I mean... look at the world of CVS. Administrators create lots of CVS
> repositories. There are automated systems out there that create lots
> of CVS repositories too. I have *never* heard of a complaint along
> the lines of, "damn, I wish 'cvs init' could automatically lay out the
> repository for me from a template.".
Know why you don't hear those complaints? CVS doesn't need any sort of
real 'repository' structure to work well, beyond what is needed to store
and build the source.
Subversion, on the other hand, essentially _requires_ a directory structure
be in place at the start to be _AT ALL USEFUL_. If you don't have some sort
of 'meta' directory structure in place above whatever it takes to store
and build your project, you lose most of the power of Subversion.
That's a pretty big difference.
> It's just not a common problem. I know the itch is intense for
> gstein, but I think he's imagining other people have this itch too,
> when it seems (to me) like people just don't. Automated scripts that
> create repositories do many things, and the template feature doesn't
> noticeably reduce the complexity of the task.
Okay, quick ... who here uses roughly the same layout for every Subversion
repository they create? I know I do ... I use /trunk /branches /tags and
/releases, at the moment, every time. I actually recently investigated (and
found out it wasn't implemented) the template feature because I was getting
tired of always creating these directories by hand.
Now, of you who use roughly the same layout for every Subversion repository
you make (I suspect that's most of you)... If there was a 'standard' wrapper
around svnadmin to set up repositories from a template, would you create
the majority of your repositories with this wrapper?
I suspect the answers for most people are 'yes' and 'yes', respectively.
(If your answers are 'yes' and 'no', respectively ... what are you, some kind
of masochist?). So assuming that's true, I have to ask:
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!
... 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_.
The current 'standard' layout has come about through real-world trials and
tribulations, and there's no good reason to force someone to read -- and
comprehend -- the entire manual just to be able to create a repository that's
going to be useful in the long term.
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. Me personally, I read the Subversion manual over several
times and monitored the mailing list(s) for months before I actively started
using Subversion in real-world projects, and I -still- didn't have a complete
grasp over everything I eventually ended up needing to know. And I'm one of
those (apparently rare) people that ENJOYS reading the manual and usually
reads it thouroughly before even touching most software.
Subversion has a per-user config file. If you don't want templates by
default, make a config option that specifies the default template name,
and set it to 'none' (or 'empty', or whatever). Problem solved. You
obviously already know quite a lot about subversion if you're going to
want to start every repository completely empty (IMHO). Don't make John Doe
newbie need to comprehend the entire manual just so that he can have a
usable tool.
... which brings me to another, related topic.
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 an arrogant stance, though amazingly common amongst unix users/admins,
I've found. But every time I see something like this, I have to fight back
the urge to start screaming at people. These applications do _NOT_ have to
be hard to use, and there's no reason to intentionally make them harder
to use because 1% of the future userbase might have to intentionally disable
some usability feature because it doesn't suit them.
[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?]
By 'future userbase' I mean 'those who would (or will) switch to subversion
as soon as the version number is stable and the barrier to entry is
acceptably low.
-jay
(Not a subversion developer, but an active subversion user, a heavy
subversion advocate, and a person getting durned tired of people she
advocates to not using subversion because the barrier to entry is so
high... and it IS high...)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 8 22:45:34 2003