Greg Stein <gstein@lyra.org> writes:
> It won't work at all. The template cannot contain a 'db' directory.
Good. But it still contains other things that don't belong in an
admin-controllable template. Quoting from your description of the
feature, the default template looks like this:
> default/
> README
> dav/
> format
> hooks/
> post-commit.tmpl
> post-revprop-change.tmpl
> pre-commit.tmpl
> pre-revprop-change.tmpl
> start-commit.tmpl
> locks/
> db.lock
Why are `dav', `locks', and `format' there?
The issue is not that "an admin might break things". The issue is
that anything an admin sees in a template, they will reasonably assume
can be customized. After all, if it can't be customized, what's it
doing in the template? The mere presence of an entity in the template
area implies that it can be tweaked.
But the `format' file's contents should never be changed. In any
given release, the repos/fs code only knows how to create one format
of repository. So `format's presence is misleading.
Similar points go for `dav' and `locks'.
That gets us down to something like this:
default/
README
hooks/
post-commit.tmpl
post-revprop-change.tmpl
pre-commit.tmpl
pre-revprop-change.tmpl
start-commit.tmpl
...with behavior (currently) unspecified for what happens if you put
files or directories other than README in the top level. If I create
the file "FISH" in a templates, does it get copied into new
repositories based on that template? What's the namespace policy
here? Do we have a reserved area that Subversion promises never to
use (you know, like the "X-foo" prefix in mail headers?) Or do we
just cross our fingers and hope that the users will never choose a
file that we later make part of Subversion (like `format')?
Concerns like the above make me think this feature has not been well
thought-out. That's not your fault -- when we discussed it on the
list before (which I forgot about, but you recall that we did), we
obviously didn't give it much careful thought, perhaps because we knew
that implementation was not imminent then. But we need to discuss it
now...
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 20 16:54:47 2003