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 > [email protected] > http://lists.puredata.info/listinfo/pd-dev > > _______________________________________________ PD-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
