[PD-dev] repository layout

Winfried Ritsch ritsch at iem.at
Wed Sep 12 15:44:22 CEST 2007


hello,

> >
> > I just missed the pdconv, so how is the authorization for the repository
> > planed ? Is it possible to restrict access to a subfolder ?
>
> no, since the plan is to stay with sourceforge for now, there is still
> no way to restrict write access to submodules (afaik).
>
> > If so I would recommend to put the trunk, tags, branches as subfolder of
> > projects which can be deligated rather then have a very long list of
> > versions for each external, subexternal or else in one directory. I would
> > prefer:
>
> so how do you like thomas grill's suggestion to do it like
> /trunk/pd/
> /trunk/externals/iem/comport
> /tags/pd/pd-<x>.<y>
> /branches/iem/comport-<x>.<y>
>
its quite the same as a general trunk,branches, tags structure.

> the problem with your suggestion i see is, that it is sometimes not
> really clear as to what is a "subproject" and what not.
> is it:
> /externals/iemlib/iemlib1/[trunk|branches|tags]
> or
> /externals/iemlib/[trunk|branches|tags]/iemlib1
> ??
but this a benefit, since with this organisation everybody know which is a 
subproject, since developerstructure is unclear now and dependencies of 
libraries are encapsulated like miXed.

>
> > since it is easy to filter out trunk in path for automatic builds, this
> > should not be a problem and everybody has freedom to organize his
> > projects with tags and branches and subfolder before tags and branches.
>
> well yes, as i have said before this is possible.
> but what is the benefit above doing it as one big project in the first
> place, if everybody who wants to checkout more than HEAD of pd-vanilla
> has to resort to setup some filtering (or use meta-projects like
> svn:externals)
>
the benefit is that its clear what is a subproject and that developer can 
organize their project like they want or also in respect of their internal 
organization, also another benefit is that with meta-project its easy to make 
bundles for automatic build systems add and remove projects without touch 
them.

>
> and finally: cvs2svn automatically creates one big project, so
> everything else would be extra work :-)
>
thats true, but much work now is less work in the future, since the delegation 
is much more clear:
 
 - Also in future when there will be (and i think it will be not to far) a 
possibility for individual access on folders, delegation doesnt need 
restructuring the repository for tags and branches.

 - its easier to give access doing branches or tags for everybody in his 
project (release early and release often ;-). 

 - if a project is removed because of any reasons (legal, personal) you dont 
need to find all branches and tags and experimental entries, since you never 
know how they are named).

Its also easier to link the projects to the softwarecenter in puredata.info, 
as you did with Gem. "One svn place for one project." 
(http://puredata.info/community/projects/software)

and I saw this structure in other community projects (like plone, etc...) 
which seems to work.

This could be the steps for finalizing the structure (so not much more work 
has to be done as the other solution):

1) just do cvs2svn 

2) do a branching tagging on basefolder like pd, pd-extented, ... not external
with svn mv, svn cp

3) tell the poeple accessing their project  they 
should do so if they want. Maybe some primitive external libraries, dont need 
it since revision numbering is enough or already finished, so just leave them 
without trunk, branches whatever...

mfg winfried




More information about the Pd-dev mailing list