[PD-dev] CVS to SVN ?

[Hans-Christoph Steiner]

On Dec 21, 2007, at 10:15 AM, IOhannes m zmölnig wrote:

> Russell Bryant wrote:
>> Winfried Ritsch wrote:
>>> eg:
>>>  externals/iem/comport/[trunk|branches|tags
>>>  externals/iem/iemmatrix/[trunk|branches|tags
>>> ...
>>>  externals/zexy/[trunk|branches|tags
>>>  externals/grill/[newlib]/[trunk|branches|tags
>>
>> However, I think that this externals structure sounds like a  
>> nightmare.
>> Personally, I would _much_ prefer the following simplified structure:
>>
>> externals/[trunk|branches|tags]
>>
>> The latter implies that there should be separate release handling  
>> for every
>> external.  That sounds like it would be confusing and cumbersome  
>> to deal with.
>> I think it makes more sense to package all of the "official"  
>> externals that are
>> in svn in a single package.  That isn't to say that you couldn't  
>> as a developer
>> check out a lower level directory from svn to work just on that  
>> section ...
>>
>
> the separate externals reflect the separate developments by separate
> (groups of) people.
> there is no "official" externals-package that are to be packaged
> together, even though pd-extended makes it look like this; but
> pd-extended is "yet another project" that is targetted at a big
> get-everything package: which is fine from an end-user point-of-view,
> but not necessarily from a developer's point-of-view.
>
> my initial arguing was, that for packages (like pd-extended) one could
> create a bundle (e.g. svn:externals) that aggragates everything needed
> in another subfolder.
> back then (search the archives for "svn migration" or similar in
> 2007-09) the the answer to this was: "we should not beta-test
> experimental features of svn" (this is what i was alluding to in my
> first response to this thread)
>
> the only other project i know where a lot of plugins by a large number
> of independent (that is: not interdependent) developers are  
> organized in
> a single svn-repository is plone, where it is handled as wini has
> proposed it (e.g. externals/zexy/[trunk|branches|tags]/)
>
> probably it would be interesting to find more case-studies than  
> just the
> one.
>
>
> one important thing (for me) is, that i want to reference the
> source-code of my library (e.g. "zexy") with a single link and  i want
> to include all the revisions of my library.
>
> i still think that one should try to find a solution that fits most
> needs, and not only a few.
> obviously there will be no solution to fit _all_ needs, but i think  
> one
> should go for "most" (aka: "as much as possible")

I liked IOhannes' original proposal, it's simple to do AFAIK and  
reflects how tags and branches have almost always been used in pure- 
data CVS:

http://lists.puredata.info/pipermail/pd-dev/2007-09/009355.html

   /trunk/pd/
   /trunk/pd-devel/
   /trunk/desiredata/
   /trunk/externals/
   /trunk/packages/
   /trunk/scripts/
   /trunk/doc/
   /tags/zexy/zexy-2.1/
   /tags/pd-extended/pd-extended-0.39.2-rc1

I've always thought of the pure-data CVS as a place where developers  
work together on code as a common platform.  People who want to be  
independent can easily make their own repositories, like Gem, PDP,  
grill, etc.  Then for Pd-extended, releases of code that is in other  
repositories can be imported into pure-data CVS.

A lot of libraries are no longer released separately from Pd- 
extended, so it is something of a standard platform.  There isn't  
anything else like it, so it's the defacto standard at least.

.hc

------------------------------------------------------------------------ 
----

Access to computers should be unlimited and total.  - the hacker ethic