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

Re: svn commit: rev 4447 - trunk/doc/book/book

From: <gstein_at_lyra.org>
Date: 2003-01-20 20:56:19 CET

On Mon, Jan 20, 2003 at 09:27:34AM -0600, Karl Fogel wrote:
 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?

'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'.

Fair enough.

...
 ...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
for repositories:

  REPOS/
    blah
    blah
    third-party/
      subwiki/
      PRODUCT-1/
      PRODUCT-2/
      ...

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:

  /usr/share/subversion-0.17/templates/...

[ most apps are vsn-keyed in /usr/share ]

 Concerns like the above make me think this feature has not been well
 thought-out.

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
 now...

In progress :-)

Cheers,
-g

-- 
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 Sat Oct 14 02:02:58 2006

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.