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

[Mathieu Roy]

Marcus Hardt <address@hidden> a tapoté :

> [..]
>
>> > I think starting a branch from the CERN one does not make sense.
>>
>> Sure.
>
> My suggestion is to implement everything with an if{$sys_hierarchy=='enabled) 
> inside the CERN tree. These parts can be merged to the main trunk at a much 
> later point.

I cannot agree with that conf variable: we are now talking about
method to create a CVS directory. Why should it be a system
configuration parameter? It should just a be a matter of using that
method or not. 


[...]

>
>
>> If you really want to do that, you should implement group association,
>> to allow admin of a project to mess with the administration of another
>> project.
>
> This is an interesting idea: One could declare a whole project subproject of 
> another project and download-dir, website-dir and cvsdir of B would be 
> subdirectories of A. B would then only be approved, if A AND the savannah 
> admin agree. Maybe admin of A should then also be admin of B.
>
> The system can reflect these information inside most entries which are 
> already 
> in the DB. Only a project would need to know, if it's a subproject, and who 
> is the parent.
>
> Might be even cleaner to implement. What do you think about this?

I think that this major change is clearly not going to happen on the
current branch which is supposed to be feature-frozen :))

I still think that you can have the desired behavior by using group
types.

I'd like to point out that it is not just up the interface to permit
that, the backend should handle a third case: no group information ;
not group type information ; but relations between the groups
themselves. 

Possible to do, but not so trivial I'm afraid. Instead of doing

         check group settings
          -no settings-> check group type settings

it would be something like 
         check group settings
          -no settings-> check parent group settings and mix that
                        settings with the group name
              -no settings-> check group type settings and mix that
                        settings with the group name

It creates one more level but the purpose is almost like the group 
type one. 
         
>> It seems lot easier to follow the method I proposed on top of this
>> mail, which would permit any project to edit a specific subdirectory
>> of a CVS.
>
> If I understand correctly I will need more than 20 group_types only for 
> CrossGrid.

Apart from the frontpage, it should not be so problematic. What would
be the problem to have a lot of group types?

I think it would be more interesting to enhance the group type than
building a parallel system with almost the same purpose.

But you have the exact worse case, a hierarchy with different levels
of depth, while the group type handle only one level of depth - and
creating a group type by level of depth is surely not an option in the
long run.


>> This is actually what we do at GNU with the CVS for homepage. Each
>> groups got a subdirectory in a big cvs called webcvs.
>>
>> However, most of the time, were are in the simple case where the
>> subdirectory have depth equal to 1.
>>
>> Otherwise (like /webcvs/blab/bla/bla instead of /webcvs/blab), were
>> forced to edit by hand, in the groupedit page, the appropriate
>> directory. This is painy but we have less than twenty groups in that
>> case ; and anyway, there's no other way to handle that.
>>
>> >> > 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.
>> >
>> > Sure? What about the "Set Active Features" page. All I'm proposing is one
>> > or two more lines there. Btw: this page allows the project admins to
>> > modify similar settings.
>>
>> This page allows projects admins to change links! Nothing more, it
>> does not involve anything real on the server. It just involves the
>> information printed on the web interface.
>>
>> >> > 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.
>> >
>> > What I think of with hierarchies is a project consisting e.g. of the
>> > following workpackages:
>> >
>> > <Project-root>
>> > WP-1
>> > WP-1.2.1
>> > WP-1.2.2
>> > WP-1.3.1
>> > WP-1.3.2
>> > WP-1.3.2.1
>> > WP-1.3.2.2
>> > WP-1.3.2.3
>> > WP-1.4
>> > WP-2.1
>> > WP-2.2
>> > WP-2.3.1
>> > WP-2.3.2
>> > ...
>> >
>> > If I want to run this with the current implementation of group_types I
>> > would need to create one group_type per node (not per leaf), (i.e. 7
>> > group_types in this short example). To me this seems to be a messy and
>> > unmaintainable configuration
>>
>> I'm not sure that I understand what is WP-1, WP-1.2.1 etc...
>>
>> Is WP-1.2 a subdirectory of WP-1?
>
> Yes, you can think of the '.' as a '/'.
>
>> If you have 5 directories each time in a subdirectory, I think that
>> you'll be forced to edit by hand the path each time: in this case, it
>> is even simpler to edit directory the subdirectory by hand in the
>> groupedit page, reserved to server admin.
>
> I could do that. Right. Will think and experiment with this one.

If you are forced to do an extra-step "this project belongs to this
one", it is maybe even faster to directly edit the group specific
variable, that override the group type, because if I understand well,
in your case very few projects can be satisfied by group type
configuration.

In your case, the faster solution would maybe even to add a special
PHP or perl script that would feed these settings semi-automatically.

For instance, you can edit the bottom of the page "groupedit" in
server admin. Maybe you could add a pointer to a PHP page of yours
where you would just have to put in a form the name of the parent
group, and these settings would get automatically fed from that
information. 

It is not the cleanest thing but it is a way that would require very
few changes on to get something working with the current branch. 




Apart from that, if you really think that a way to make project
considered as part of other projects, independantly of group type,
should be implemented, you should details exactly how you would like
to implement that and propose a timeline. It would be a good starting
point to open a new  development branch -- but as you said, only after
the current branch is merged in the trunk.

I understand that your solution is probably the cleanest way to do a
hierarchical system with different level of depth ; so in the end, I
would not be against such an implementation. But right now I'm more
concerned about having every existing things working as expected.

As said before, you are exactly in our case, at GNU, of /webcvs. But
fortunately, we usually have only one level of depth.

Regards, 

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