[PD-dev] CVS to SVN ?

[Luke Iannini (pd)]

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 at 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 at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>