savannah-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Savannah-dev] Re: Future of new CVS handling


From: Mathieu Roy
Subject: [Savannah-dev] Re: Future of new CVS handling
Date: Tue, 02 Dec 2003 09:21:06 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Marcus Hardt <address@hidden> a tapoté :

> Hi Mathieu!
>
> I'm just starting with the CVS handling. So far I've seen what you modified 
> in 
> sv_groups, the DB and in the frontend.
>
> I will want to add three modifications to that:
>
> 1. The dir_type_cvs = "subdir-cvs" creation method will need a parameter. 
> Thus 
> I'd like to add dir_type_cvs_paramset, dir_type_homepage_paramset and 
> dir_type_download_paramset, which would contain a list of parameters, 
> separated by ';' used for future extensions.

I do not clearly understand what would be the content of this
dir_type_cvs_paramset.

At this status, I'm not exactly open to additions in the database
unless it is a bugfix.

Why would you like to put a specific set of parameters? You directly
handle that in the Cvs modules. Giving parameters is only useful when
there is something to configure.

What would be the creation of a cvs subdir, apart a basic directory?


> 2. The dir_type_* tool should be changeable per group as well. I'd add the 
> tables and the code. This will raise the security issue: Project admins could 
Please, do not do that. I would not like to end up with an interface
where everything can take three hours to be configured:

There is no point in having differents groups in the same group type
if they do not share the same basic configuration. What you propose is
just to override the group type settings everywhere. 

The way to go is to create a different group type each time the
configuration must differ. If it must differ at each group, it is
surely easier to create groups by hand.


> start hacking, by using a leading '/' for the dir_homepage for
> instacne. For apache (web and download) that might be save, for cvs
> this isn't.  We need to rely on proper coding of sv_groups and all
> the *.pm modules.  This can be done, by treating the directory given
> for the group as a subdirectory of the group_type. For example:
> <group_type.dir_cvs>/ <group.dir_cvs>

Project admins MUST NOT be able to modify these settings, in any case.  


> 3. I foresee that the group configuration will depend on the
>dir_type_<feature> chosen in the group_type. I.e. the parameters that
>can be specified by a group-admin might be a checkbox, a selection or
>an input field.
>
> What do you think?

I think that I would prefer if you try using the group type to handle
different group configuration you have instead of implementing a
configuration for every field.

Savannah already reached a level of complexity far more important than
what is actually do. Having a tool that is easily configurable and can
be installed outside GNU is what we achieved recently.

I would not like to see Savannah going in the other extreme position:
everything configurable but 5 hours to configure an half of the
system.

A portable function of creation of a CVS repository should take
something like 50 parameters. The fastest thing to do is to hardcode
directly the expected method.


-- 
Mathieu Roy

  +---------------------------------------------------------------------+
  | General Homepage:           http://yeupou.coleumes.org/             |
  | Computing Homepage:         http://alberich.coleumes.org/           |
  | Not a native english speaker:                                       |
  |     http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english  |
  +---------------------------------------------------------------------+




reply via email to

[Prev in Thread] Current Thread [Next in Thread]