[PD-dev] repository layout

B. Bogart ben at ekran.org
Tue Sep 11 21:46:32 CEST 2007


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
> 





More information about the Pd-dev mailing list