[Top][All Lists]
[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