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