[PD-dev] repository layout

Wed Sep 12 14:46:21 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 ?

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:

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.

Please even its not possible today to give authorization to subfolder, it will 
be in near future and so the repository becomes readable finding tags and 
branches und we need not website for it to give short links.

mfg winfried

>
> Also, the same goes for the trunk, I think we should think of all this
> stuff as one big project, or one meta-project if youwant to thikn about it
> that way.  So I agree with IOhannes, having the subfolders in trunk rather
> than the trunk in the subfolder, i.e.
>
>     /trunk/pd/
>     /trunk/pd-devel/
>     /trunk/desiredata/
>     /trunk/externals/
>     /trunk/packages/
>     /trunk/scripts/
>     /trunk/doc/
>
> About desiredata, as Matju stated, the plan is to not remain in
> synch with the code, but instead be compatible (sounds like a good idea,
> by the way).  Therefore, it probably makes sense to have desiredata in
> it's own repository.  But I suppose there is not harm done having a
> 'desiredata' trunk.
>
> As for 'scripts', there needs to be a place for all the scripts needed to
> build Pd-extended.  Whether that's also the place for bash_completion,
> etc, that's a separate question.  What do other projects do for this
> stuff?  This is not a unique question...
>
> .hc
>
> On Tue, 11 Sep 2007, B. Bogart wrote:
> > Hmmm I think the placement of trunk/tags/braches depends on what those
> > things mean for PD...
> >
> > Does it makes sense to have a branch of everything in CVS (as you
> > suggest here) or a branch of just externals or PD (as frank's suggestion
> > would do) or even to have a branch of a particular external then
> > pd/externals/grill/branches.
> >
> > I suppose you can copy a branch of just stable externals and put them in
> > the root "branches" but my understanding of SVN was that these
> > trunk/branches etc.. were per project... One trunk folder for everything
> > does not make much sense to me...
> >
> > .b.
> >
> > IOhannes m zmoelnig wrote:
> >> hi.
> >>
> >> after the talk about svn at the pd-con, it seems like there is a general
> >> ok from the community, if somebody would be willing to perform the
> >> actual migration.
> >>
> >> actually i could be this volunteer.
> >>
> >>
> >> ad miller: there exist migration paths from both cvs and svn to git, so
> >> svn would do no harm before we can switch to git :-)
> >>
> >>
> >> about the structure:
> >>
> >> i have written down some ideas on how an svn-repository could be
> >> structured at http://puredata.info/Members/zmoelnig/pdcon07/SubVersion
> >>
> >> basically the layout keeps the same, but with svn-specifics like
> >> meta-directories "trunk", "tags" and "branches".
> >> ideally (for me) the layout of "trunk" would be:
> >>   /trunk/pd/
> >>   /trunk/pd-devel/
> >>   /trunk/desiredata/
> >>   /trunk/externals/
> >>   /trunk/packages/
> >>   /trunk/scripts/
> >>   /trunk/doc/
> >>
> >> differences to the current layout are:
> >> - moved abstractions&extensions&xgui&Framestein into externals
> >> - desiredata&pd-devel live beside "pd" (not in a separate branch)
> >> - htdocs is deprecated (but could as well move into "doc")
> >> - "supercollider" has moved into scripts (i am not sure about this, but
> >> it seems to be the best place, since "bash_completion" is already in
> >> there; "supercollider" is no external, it is rather a set of sc3-scripts
> >> to ease the use of pd&sc together)
> >>
> >>
> >> the layout of "tags" would be:
> >>   /tags/pd-0.40-4/
> >>   /tags/pd-0.41-1/
> >>   /tags/desiredata-0.39-1/
> >>   /tags/zexy-2.1/
> >>   /tags/pd-extended-0.39.2-rc1
> >>   ...
> >> (that is: a _very_ flat structure of "released" code)
> >>
> >> the layout of "branches" would be almost the same as that of "tags" (but
> >> "tagged" revisions should not be touched any more, whereas "branched"
> >> revisions can be bug-fixed...)
> >>
> >> both branches/tags should only be used for:
> >>   - releases (+maintenance)
> >>   - legacy (discontinued) projects
> >>
> >> it is my believe that tags&branches should mainly be used for people who
> >> want to checkout "working code" (!), rather than developers who want to
> >> try something out without interfering with the existing code-base
> >> (trunk)
> >>
> >>
> >> for quick experimental branches (e.g. if you want to implement a feature
> >> but do not want to spill the trunk), i would suggest a 4th
> >> meta-directory "experimental", like:
> >>   /experimental/pd-0.40-kiosk/
> >>   /experimental/pd-extended-0.39-newbuildsystem/
> >> projects in "experimental" are not meant to be continued, but their
> >> changes should go back into the main trunk (either by merging into the
> >> original project or by living besides it)
> >> in any case, these experimental branches should be deleted when
> >> finished, in order to keep the directory-layour reasonably small.
> >>
> >>
> >>
> >>
> >> comments are highly welcome
> >>
> >>
> >> fgmasd.r
> >> IOhannes
> >>
> >> _______________________________________________
> >> PD-dev mailing list
> >> PD-dev at iem.at
> >> http://lists.puredata.info/listinfo/pd-dev
> >
> > _______________________________________________
> > PD-dev mailing list
> > PD-dev at iem.at
> > http://lists.puredata.info/listinfo/pd-dev
>
>  	zen
>  	   \
>  	    \
>  	     \[D[D[D[D
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev