Just wanted to throw in my support for the individual [trunk|branch|tags] arrangement. It's nice to be able to branch often when doing experimentation, and I think it would get quite messy if everyone was throwing their branches into a common externals/branches dir. It will also be easier to parse "svn log" if things are separated by project.
I'll also second the use of svn:externals as an internal "symlink" system. It's extremely handy (if a little space-inefficient), and Pd-Extended would probably be much easier to work with since only the things that are actually included could be linked in from the externals etc. and organized however
I'm also volunteering as an "SVN ambassador" : ), and would be happy to walk people through branching/tagging/reverting/rescuing files/merging and so on.
Cheers Luke
On Dec 21, 2007 10:15 AM, IOhannes m zmölnig zmoelnig@iem.at 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")
m.fda IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev