On Mon, Jan 20, 2003 at 09:27:34AM -0600, Karl Fogel wrote:
Greg Stein firstname.lastname@example.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:
Why are `dav', `locks', and `format' there?
'db' isn't there because it requires special construction and
initialization. The others are there because they can be :-)
I'm not particularly wedded to them, and would be quite fine with either
leaving them (to assist in seeing the overall look), or tossing them.
We can have the repos code ensure they are present after applying the
template, or we can have it bail if they were created by the template. I'd
probably take the former behavior. (be lenient in what you accept)
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'.
...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')?
So define a policy. For the subwiki stuff, I asserted a structure like this
I think that I even had a conf/subwiki.conf in there at one point.
If that makes sense, then we can go ahead and impose that.
btw, I was planning to put these policies and detailed instructions into a
README in the trunk/templates/ subdirectories.
One more note about namespace protection. The templates should be keyed to
the version of SVN. Thus, a template won't accidentally be used against the
wrong version. For example:
[ most apps are vsn-keyed in /usr/share ]
Concerns like the above make me think this feature has not been well
Yah. I got the code in there, but there is certainly some non-code polishing
that can be done, along with some code tweaks, I'm sure.
[ I'm still waiting for the bikeshed discussion on the terms on-disk and
in-repos :-) ... seriously, though: suggestions welcome ]
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
In progress :-)
Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Oct 14 02:02:58 2006