[PD-dev] repository layout

[Hans-Christoph Steiner]

I use branches of the whole thing for Pd-extended, so I like this layout:

/branches/pd-extended/pd-extended-0-40-3

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