[PD-dev] repository layout

Thomas Grill gr at grrrr.org
Tue Sep 11 16:49:19 CEST 2007


Hi,
sounds very reasonable to me.
The only potential problem that i see is the flat hierarchy (resp.  
naming scheme) of the branches and tags. It seems that this folder  
would populate quite fast and might quickly become a mess. On the  
other hand it's quite easy to clean it up again with svn ;-)
Btw., where would the svn repository be located?

greetings, Thomas

Am 11.09.2007 um 16:35 schrieb IOhannes m zmoelnig:

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





More information about the Pd-dev mailing list