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

[Marcus Hardt]

On Tuesday 02 December 2003 15:11, Mathieu Roy wrote:
> 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.

Yep, but I think it's easiest to avoid merging these into the main trunk. 
However, that was a quick shot and is defnitely not clean!

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

O.k. looks like quite some work.

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

Well, then I could do most things by hand as well.

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

I'm ready to enhance the group type ;-)

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

Well, not only would that require one groupt type per depth, there would be 
one per directory node.

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

I hope I don't need an additional DB table for that. I will see. Might even 
be, that I just turn off the backend for my solution until the CERN branch is 
merged.



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

O.k. I will think things through and most probably go for an intermediate 
solution.

-- 
Marcus