savannah-dev
[Top][All Lists]
Advanced

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

[Savannah-dev] Re: Merging GNU Savannah and the CERN branch


From: Marcus Hardt
Subject: [Savannah-dev] Re: Merging GNU Savannah and the CERN branch
Date: Thu, 4 Sep 2003 16:37:06 +0200
User-agent: KMail/1.5.3

On Thursday 04 September 2003 16:25, Mathieu Roy wrote:
> Marcus Hardt <address@hidden> a tapoté :
> > On Thursday 04 September 2003 13:34, Mathieu Roy wrote:
> > > Marcus Hardt <address@hidden> a tapoté :
> > > > Hi!
> > > >
> > > > The database removing/renaming/adding seems a serious step to me,
> > > > which should only be done once.
> > > >
> > > > At savannah.fzk.de we added two extra tables to the database which
> > > > I'd like to find in the refurbished savannah once we start merging
> > > > our branch.
> > > >
> > > > For the way we handle the subdirectories of CVS we need these entries
> > > > in the groups table:
> > > > CREATE TABLE groups (
> > > >   cvs_subdir varchar(100) NOT NULL default '',
> > > >   cvs_subdir_of varchar(100) NOT NULL default '',
> > > >   use_cvs_subdir int(11) NOT NULL default '0',
> > > > }
> > > >
> > > > In case you plan to change the cvs handling itself I'd like to be
> > > > involved in the discussion
> > >
> > > We will change the cvs handling itself because we'll add some modular
> > > support for cvs/arch/subversions. We will surely not keep database
> > > field with "cvs" within their name but names less specific.
> >
> > o.k. I'm not happy with how I added my extensions. I modified
> > gnuscripts/sv_aliases just before all its changes where reset to a way
> > older version. Best will be if I participate when you redesign these
> > codesnippets in order keep our functionality available.
>
> Basically, we are going to clean the database, so we need to know
> exactly what kind of information you need to provide.

O.k. what I needed to do was to have one CVS tree for one (big) project. (This 
project is the EU project CrossGrid.) It is composed of a couple of 
Workpackages that decompose into Tasks. Each of these Tasks wants to have 
it's own savannah project and needs to (write) access parts of the project's 
cvs. 
To accomplish this I was using three entries in the group table:
o int use_cvs_subdir: to indicate if a project needs that feature
o varchar cvs_subdir_of: to specify which project owns the maintree
o varchar cvs_subdir: to specify the directory where to branch off

This is quite messy since you have to compose a couple of paths from the 
group_type's and group's cvs directory specifications.

There also is an administrative frontend which is far from useful for other's 
than the implementor. The implementation being on top of the existing 
infrastructure was quite messy in my eyes and I would not like to do that 
again. Especially if this feature can be thought of, when redesigning 
cvs/arch/subversions.


[..]  

-- 
Marcus





reply via email to

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