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

Re: The `on_disk' and `in_repos' templates.

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-04-10 13:31:34 CEST

I get the feeling that you're replying to my mail as if I was making
suggestions. I wasn't. :-)

I'd like to get people (both those that support the idea of templates
and those that don't) to start thinking about features, behaviour, and
the consequences of same on their design. I've heard a lot of "scripting
is best" vs. "out of the box is best" noise, but very little useful
content. Let's first figure out *what* we want to do, before fighting
about *how* we're gonna do it.

Wolf Josef wrote:

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

O.K., that seems like a sensible approach.

>But would
>it hurt if the location of the templates would be a config-option?
>

A config option, sure; but where?

>> * 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?)
>

No, the conf directory isn't used yet. But that's just one small item.

>> What does such a move do to ease of installation?
>>
>>
>
>Well, it saves you some steps when you create a repos :-)
>

What I meant was, how would it affect the ease of installation of
Subverison, not the ease of repository creation. These are two different
things.

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

Really? mkdir where? vi/emacs what? I'd like to see specific discussion
about a) how a management tool will locate the templates, where and how
the templates are documented, etc. etc.

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

I expect so. But I'd like to see more concrete examples: what could or
could not be done about directory layout, properties, revprops? Could
you just create a fixed starting point, or could you determine the
future behaviour of the repository?

>> * 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?
>

I dunno if it would hurt, I'm asking if it's possible, and how, and what
the implications are.

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

Again, what are the arguments for one or the other side?

>>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:
>

What you describe is a particular implementation of the template
concept, it's not a design. A particular design is implied by the
implementaiton, of course, but I'm more interestied in the reasons why
you chose this particular set of features, rather than the features
themselves.

I hope people aren't getting the impression that I'm being difficult
just for the hell of it (again). I'm not. Probably 99% of the features
in Subversion right now are in some way direct consequences of the
original goal to "make a better CVS". However broad that statement was,
we started out with a farily coherent interpretation of it and IMHO did
a fairly good job of sticking with it.

This templates thing is something completely new, not in any way evolved
from that original goal. That's why I'd like to see discussion about
very basic principles and core requirements. The core goal might even be
"make repository creation easier," even though that covers a multitude
of sins.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 10 13:32:19 2003

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.