Branko Cibej wrote:
> * Installation. Where are the templates installed, on various
> systems? Do you have a single set of templates, or separate sets
> for different project groups?
IMHO all the templates should be located in one specific directory on the server. I don't think that different groups need different sets. And if
they need, they can always distinguish them by some naming-sheme. But would
it hurt if the location of the templates would be a config-option?
> * Integration. Does the default repository (on-disk) layout remain
> hard-coded, or does it gradually move into the on-disk templates?
What are templates good for if you leave everything hard-coded? The
question is: _which_ parts should move. IMHO the hook directory and
the conf directory should move. (AFAIK the conf directory is not used
yet, is it?)
> What does such a move do to ease of installation?
Well, it saves you some steps when you create a repos :-) Not a big deal.
The benefit is very limited if you do not extend the functionality beyond
the creation of the repos. Therefore I think there should be a tool for
creation _and_ maintanance of the repos. Templates are just a part of the
creation process.
> * Maintainability. How do you maintain/modify the templates? How do
> you document them? What tools do you need (e.g., for locating the
> template installation, etc.)
mkdir and vi/emacs should do the trick for the first steps.
> * Filesystem features (for in-repos templates). What features of the
> filesystem can you control with the templates? Directory layout,
> properties, revprops?
All of them would be desireable.
> * Back-end features (for on-disk templates): Again, what features of
> the on-disk structure can you control with the templates? Thinking
> ahead, can the template idea be extended to non-Berkeley
> back-ends? What about DB_CONFIG or equivalent configuration files?
Would it hurt?
> Does the template determine the back-end type, or the other way
> around?
The template should define the back-end-type. The other way does not make
much sense, IMHO.
> In short, what I'm asking for is a design discussion, starting with
> basic requirements.
OK, here comes an overview how templates are currently designed in the
svn-admin script:
Templates are sub-directories in a (install-time) configurable directory.
On my box, I have put them into /m/svn/templ. A template directory contains
a subdirectory named "contents", which is the source of any initial files
and directories. Further, the template-directory contains a number of
configuration files. For example, the "example" template from svn-admin
contains the following files/dirs:
/m/svn/templ/example/contents/trunk/
/m/svn/templ/example/contents/trunk/Makefile
/m/svn/templ/example/contents/trunk/getversion.pl
/m/svn/templ/example/contents/tags/
/m/svn/templ/example/contents/branches/
/m/svn/templ/example/contents/releases/
/m/svn/templ/example/contents/imports/
/m/svn/templ/example/cicnf # commit-acceess configuration
/m/svn/templ/example/emcnf # commit-email configuration
/m/svn/templ/example/properties # initial property settings
the /m/svn/templ/example/properties file looks like this:
/ svn:ignore "*.obj *.o *~"
/trunk/Makefile svn:eol-style "native"
/trunk/getversion.pl svn:eol-style "native"
/trunk/getversion.pl svn:keywords "HeadURL LastChangedDate"
/trunk/getversion.pl svn:executable ""
Clearly, this structure is not perfect. But no one denies to evolve it to
a better one ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 10 12:38:01 2003