[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