This mail is about two semi-independent things: the `on_disk' and the
`in_repos' template arguments to svn_repos_create(). Their
corresponding arguments to svnadmin are:
$ svnadmin create --on-disk-template FOO --in-repos-template BAR
[I suppose I could send two separate mails, but what the heck.]
The idea behind on-disk templates was that there would be certain
repository setups admins would want to repeat over and over -- the
main thing being that one would often want the same hook files in
different repositories.
The idea behind in-repos templates is that, even though Subversion
repositories are technically free-form, in practice we want to
encourage the adoption of certain standards. (One example would be
the layout we use in Subversion's own repository.) The best way to
encourage a standard is to make it very convenient to follow the
standard; hence the templatizing.
Regarding the on-disk template:
I think this functionality should be implemented as a wrapper script
around svnadmin, since it's essentially a matter of copying some
files, instead of by svnadmin itself. I would have made noise about
this earlier if I'd been better able to articulate my thoughts.
(I think there was also some miscommunication around the original
discussion of these features, but my recollection could be faulty.
Anyway, I don't really care exactly how it happened, let's just
discuss the situation as it is in the present.)
The argument against this "just use a wrapper" strategy, of course, is
that a wrapper would not be as portable as svnadmin itself. Even if
you don't have Python, Perl, or even Bourne shell on your box, you
have svnadmin (since you managed to build Subversion). So we could
ship a wrapper script, or scripts, but we could never advertise them
as the The One True Way to create a repository, since some people
might still have to use 'svnadmin create' to do it. Therefore, the
argument goes, it's better to have this functionality directly in
Subversion.
In the real world, though, I don't buy it. Most admins don't create
repositories all *that* often. And when they do need to customize a
newly-created repository, their customization needs generally won't be
satisfied by the limited set of actions available through
`--on-disk-template' (basically, all it can do is copy, and that's
rarely enough). Sure, I've seen new CVS admins post questions about
setting up new repositories, but their questions are usually answered
pretty easily. I honestly don't think Subversion will see *fewer*
questions because it has the `--on-disk-template' argument; it'll just
see different questions, such as "How do I use that argument? What
does it mean?" :-)
There are sites (SourceForge, for example) that create new
repositories in large numbers. But in systems like that, you can be
even more sure that `--on-disk-template' is not going to help them
much. SourceForge and similar systems *already* have custom code
wrapping repository creation, and by necessity they have people who
understand repository creation intimately. If they use Subversion,
it's no trouble for them to add a couple of lines of code to copy some
hook scripts... Certainly, no more trouble than it would be for them
to understand the --on-disk-template argument, make a template, and
pass the argument correctly. From the user perspective, these two
tasks are pretty much equal in complexity.
But they're not equal in code complexity. By supporting the
templating internally, we've added a maintenance burden to our code
(including even to the svn_fs API at the moment, which is really sad).
It's a needless, dormant bug source in Subversion, and it uses C code
for tasks which are more easily and flexibly done by scripting.
Blecch -- me no like :-).
So there you have it. I don't think the --on-disk-template argument
really helps anyone, and it hurts us. I'd like to get rid of it.
Does anyone object?
Regarding the in-repos template:
The idea behind this was to encourage a standard tree layout. Lately,
the layout we seem to have settled on (and the one that the Subversion
book is planning to document as The Recommended Layout) looks like
this:
/Project1/trunk
/branches
/tags
/Project2/trunk
/branches
/tags
In other words, there is the idea of a "project root", and the first
things under every project root are three directories: trunk,
branches, and tags. Project roots are often located in "/", but not
always. (For example, our repository has the "/clients/" directory,
which contains, say, "/clients/rapidsvn/" as one of three project
roots beneath it).
Maybe there will be repositories in the future that use slightly
different layouts, I don't know. This layout does seem to be working
pretty well, though, and I think we'd have to recommend it as at least
one of the proven layouts.
I don't mean to start a thread about layouts. My main point is, this
particular layout isn't susceptible to automation at repository
creation time, because the layout happens when you create a new
project root. Again, the right solution is a wrapper script
"svn-project-create.py" or something. The script could use the fs
bindings to create the project and all three subdirs in one txn, so it
only uses 1 revision instead 4.
While we should do everything we can to promote a standard layout, to
encourage easier cooperation, we shouldn't be coding it into
`svnadmin' (and certainly not into the svn_fs API). We can do it just
as well via documentation and examples and scripts.
And note that the feature is not actually implemented anyway! The
in_repos_template argument to svn_repos_create() does nothing right
now [though the doc string neglects to mention this, tsk tsk]. Thanks
to Makl, who mentioned this in issue #1222.
I'd like to remove the `--in-repos-template' flag from svnadmin, and
from the FS api as well; it was a noble intention, but I think in the
light of experience, it does not hold up as a solution.
Any objections?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 7 19:57:44 2003