Georg Holzmann wrote:

Hallo Russell !

...

I really don't intend to start a SCM war here, but has the discussion of switching to using svn on sourceforge instead of cvs ever come up before?

This was discussed many many times before and at the pd-convention it was decided to switch to SVN.

i would rather say: it was decided that if somebody volunteers to do the work, nobody will object.

i volunteered to do the work. after fruitless discussions, i decided to not push the switch any more. (though i still would like to work with subversion)

the main counter-argument against svn was, that everything that cannot be done with CVS was considered as "experimental" and "should not be used", in which case i don't see a reason to do the work.

So yes, this will be done AFAIR.

or rather, no, it won't be done AFAIK.

i am currently thinking of starting an svn-repository in parallel to the CVS-repository (both at sourceforge) and whoever wants to move over should just do it, and leave a notice in the CVS, that the content has moved.

mfa.sdr IOhannes

David Plans Casal wrote:

I have witnessed this happen in a separate project, and it isn't as bad as it sounds.

However, politically, there is obvious reasons not to.

Do you mean that there are obvious reasons not to switch? or to not run cvs and svn in parallel?

I certainly don't want to stir up any project politics here. But, if there are obvious reasons why it shouldn't be done, then that's what I'm trying to figure out. :)

-- Russell Bryant

Frank Barknecht wrote:

I think, the main obstactle always was that people were suggesting other alternatives than SVN to switch to from CVS, then the discussions turned into one about the merits of the various RC-systems and then the discussions always died off.

Yes, that is the exact discussion I want to avoid. :)

I think it is quite nice to use the existing project infrastructure at sourceforge. So, nothing else is really even an option without a _lot_ more work.

So yes, to limit the scope of the discussion, I am simply interesting in the possibility of migrating from sourceforge cvs to sourceforge svn.

-- Russell Bryant

Hello,

[...]

...

So yes, this will be done AFAIR.

or rather, no, it won't be done AFAIK.

i am currently thinking of starting an svn-repository in parallel to the CVS-repository (both at sourceforge) and whoever wants to move over should just do it, and leave a notice in the CVS, that the content has moved.

I also suggest, even because of reason, to to external reference libraries from IEM to projects in our svn, that we start the migration and everyone who wants his project also to switch over can do so or ask help that this is done.

So I would suggest start the svn tree with externals and when we move our externals to svn we check in a note where to find then into cvs.

If someone gives me the rights for the svn I can start.

mfg winfried -- - ao.Univ.Prof. DI Winfried Ritsch - ritsch@iem.at - http://iem.at/ritsch - Institut fuer Elektronische Musik und Akustik - University of Music and Dramatic Art Graz - Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171 - PGP-ID 69617A69 (see keyserver http://wwwkeys.eu.gpg.net/) --

Miller Puckette wrote:

Yeah, start the tree, I'll be happy to move pd 'head' right on over :)

Well, that sounds like a pretty official green light to me!

Also, just in case someone wanted to use git to manage their personal development, there appears to be pretty good git/svn support. ;) You should be able to easily use git to manage code locally, with bidirectional access to the upstream svn repository.

http://www.kernel.org/pub/software/scm/git/docs/git-svn.html

-- Russell Bryant

Winfried Ritsch wrote:

a) we start a parallel svn-tree.

with at least a two folder:

externals pd

where externals and pd come in.

b) Every "main-in-charge-projectleader/group" of a project can move their project to svn, either to ask someone to do so or doing himself.

I think it would be a bad idea to maintain any sort of parallel systems. I would rather see a "flag day" where everything gets moved, and the CVS repository is shut down, or set as read-only, with a pointer over to SVN.

Also, from point b, it sounds like you intend that things should be moved over manually. However, the process for converting a cvs repository to svn is automatic and will convert everything. I think it would be a bad idea to move anything manually, as you will lose all of the commit history, which would be extremely unfortunate.

c) structure:

We should use the external basefolder for all externals. But the naming and subtree can be changed and grouping to developing groups for future delegation options.

(I recommend to put the trunk, tags, branches as subfolder of projects rather then have a very long list of versions for each external, subexternal or else in one directory. )

"Each project should have their a trunk,branches,tags"

eg.:

pd/[trunk|branches|tags]

Yes, I would agree with this structure.

... externals/[some external name]/[trunk|branches|tags] ...

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

Anyway, I'm brand new around here. I think I'm getting beyond the point where my opinion matters. I'm just glad that the general consensus is to switch to svn. :)

Again, I would be happy to help do the work, but it sounds like there are those that have been around longer that are already willing to do it.

-- Russell Bryant

Winfried Ritsch wrote:

I think with cvs2svn.sh you convert all history and it is the same as converting the whole thing or a subtree.

Oh, ok, I haven't looked at cvs2svn in a while, and assumed that it wouldn't let you convert pieces at a time of the same repository. If it does, cool.

-- Russell Bryant

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

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

I think we are in agreement with that the CVS should be a place to gather things too, these things are not mutually exclusive. I don't see any substantial advantage to maintaining parallel build systems. I think ideally, there would be a common build system, so that people can just plug their stuff into it and not have to worry about writing their own build system, porting to various platforms, etc.

The Pd-extended build system does this to some degree, but definitely could be improved a lot. Currently if you want to build just one section using a common build system, say sigpack, you can do this:

cvs co pd externals/Makefile externals/sigpack packages/ Makefile.buildlayout cd externals make sigpack && make sigpack_install

or this:

cvs co pd externals/Makefile externals/sigpack packages/ Makefile.buildlayout cd externals/sigpack make && make install

As for using svn:externals for reorganizing build systems, that seems to just be creating more work for each custom distro. I think this would be much better handled using a common autoconf system, so you could do something like:

cd externals ./configure --disable-all-externals --enable-iemmatrix --enable-zexy make && make install

Then you'd get a custom build of the whole thing with no SVN trickery needed.

.hc

On Jan 1, 2008, at 8:02 AM, Winfried Ritsch wrote:

Hello,

...

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.

I always thought of the pure-data CVS as a market place where everyone can put their open source projects like libraries of externals, so a user can find them there und do not need to make a own web presence and CVS/SVN and also make it easier to make an extend release or for everyone to build their own extended version of pd.

This is why we put the iem-libs in there and not in the IEM-Opensource http://sourceforge.net/projects/iem repositories. The problem that every developper change the source if we cant react in an proper time was because we trust in other developers unlike some other projects like PDP, grill or GEM...

...

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.

But they are still in CVS so they are released as head and if somebody need it, it can be fixed if something is broken, so these libraries are in my opinion not dependent on "pd extended".

BTW, I also like to state, that I prefer as less dependencies from one project on another if not depended on shared resources other than build systems, eg. Makefiles in the parent is really a mess to include this externals in a project.

I think, if we solve this problem the decision of how to organize the code will be clear.

mfg Winfried Ritsch

PS: Who askes the developer on sf on transition. I have no admin rights until now, so I think someone from the admins should do the job.

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

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

As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin

On Jan 2, 2008, at 2:52 AM, IOhannes m zmoelnig wrote:

hi

Hans-Christoph Steiner wrote:

...

As for using svn:externals for reorganizing build systems, that seems to just be creating more work for each custom distro. I think this

i don't know.

what i do know is, that in _our_ custom distro, i have to explicitely "cvs checkout" the needed externals. this seems more cumbersome than using "svn:externals". additionally, i patch the build-systems of the externals in order to fit. i think this is more tiresome than not patching it.

as for pd-extended it obviously would be more work in the migration, as the current build-system is organized around this single distro.

so i cannot really follow your argument here.

The idea would be like this:

svn co pure-data cd pure-data/packages/darwin_app ./configure --disable-all-externals --enable-zexy --enable-iemmatrix make && make package

And voila, you have your custom distro. For a different platform, you would do this:

svn co pure-data cd pure-data/packages/linux_make ./configure --disable-all-externals --enable-zexy --enable-iemmatrix make && make package

I suppose ideally, the ./configure would specify the package type too, like this:

svn co pure-data cd pure-data/packages ./configure --disable-all-externals --enable-zexy --enable-iemmatrix \ --enable-darwin-app make && make package

This would eliminate the need to do any kind of special CVS/SVN checkouts when building custom distros. A lot of this already works. It's not pretty, and could be improved a lot, but there is something to build on.

As for requiring the "packages" section, there is no reason why it is that why it is that way beside that is the way that it currently works. I think that all of this stuff probably should be included in pd/src/configure.in.

.hc

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

As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin

On Jan 3, 2008, at 3:39 AM, IOhannes m zmoelnig wrote:

Hans-Christoph Steiner wrote:

...

On Jan 2, 2008, at 2:52 AM, IOhannes m zmoelnig wrote:

svn co pure-data cd pure-data/packages/darwin_app ./configure --disable-all-externals --enable-zexy --enable-iemmatrix make && make package And voila, you have your custom distro. For a different platform, you would do this:

ah, i think we do not agree on what a "custom distro" means. it seems like for you, a custom distro is a (possibly stripped) flavour of the full pd-extended distro. for me, a custom distro is (e.g.), a pd-application that needs several externals and comes with all these externals.

It sounds like we have the exact same idea of custom distros. For me, Pd-extended is a specific distro that includes a wide range of things that is intended to be the same on all platforms, like how Debian is the same on all the different CPUs/platforms. What I am describing is a common build system that can be used to make any distro, from pd-extended to a pd-application that you describe.

please let's not go into the "why don't you use pd-extended then" discussion again.

...

As for requiring the "packages" section, there is no reason why it is that why it is that way beside that is the way that it currently works. I think that all of this stuff probably should be included in pd/src/configure.in.

please never ever. put it into cvsroot/pure-data/configure.in, but leave out pd/src/ and the kernel-configuration.

I don't understand the objection to using a directory called "packages". How is that any different than "externals"? I don't think it's a great layout, but it isn't bad, and it is about as good as we can get considering that the "pd" section is basically off limits. I am open to suggestions to improvements, but "it is bad" isn't helpful or constructive.

.hc

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

All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne

On Jan 28, 2008, at 1:12 PM, IOhannes m zmoelnig wrote:

Hans-Christoph Steiner wrote:

...

On Jan 3, 2008, at 3:39 AM, IOhannes m zmoelnig wrote:

It sounds like we have the exact same idea of custom distros. For me, Pd-extended is a specific distro that includes a wide range of things that is intended to be the same on all platforms, like how Debian is the same on all the different CPUs/platforms. What I am describing is a common build system that can be used to make any distro, from pd-extended to a pd-application that you describe.

what i mean by pd-application is centered around the application rather than pd: the app just happens to be written in Pd and comes with externals as needed. an example for such an application is iem's CUBEmixer (https://iem.svn.sourceforge.net/svnroot/iem/spatialization/ CUBEmixer/trunk)

That's what I am talking about as well, I've started to do some work to support this kind of distro with the embedded preferences stuff.

...

...

put it into cvsroot/pure-data/configure.in, but leave out pd/ src/ and the kernel-configuration.

I don't understand the objection to using a directory called "packages". How is that any different than "externals"? I don't

i have no objections to using a directory called "packages". i was only objecting to put every single configuration into pd/src/ configure.in

Yes, "every single" is not a good idea, but anything that Pd might use should be handled there and then shared to the externals.

...

limits. I am open to suggestions to improvements, but "it is bad" isn't helpful or constructive.

pd/src/configure.in is the configuration of pd-core (vanilla,...) imho, it is not the place for the configuration of (e.g.) zexy.

I think that Asterisk could provide a good model with its "applications" and other plugins. While many of them are contributed from others, they are all options in the ./configure and "make menuconfig" system.

.hc

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

kill your television

On Jan 29, 2008, at 9:15 AM, Russell Bryant wrote:

Hans-Christoph Steiner wrote:

...

I think that Asterisk could provide a good model with its "applications" and other plugins. While many of them are contributed from others, they are all options in the ./configure and "make menuconfig" system.

Thanks. :)

However, I'm not sure that our model could apply to Pd. Asterisk is distributed as one monolithic source package, because it is maintained by a core development team sponsored by a company. Pd development is much more fragmented than that, and the source layout reflects it.

Given the way the Pd core is developed and released, it seems that integrating any other things from externals and so forth into the pd-core build system is pretty much out of the question. I agree with IOhannes that the configure script and the rest of the build system for pd-vanilla should, at least for the foreseeable future, stay only related to the pd-vanilla stuff itself.

However, it's possible that the configure/menuselect system that we use could be applied to the externals directory. The basic idea is that there is a single configure script that checks for the presence and usability of libraries and other system-dependent features than any module cares about.

Then, menuselect (menuconfig) serves a couple of purposes. It reads information about what libraries modules depend on, or what other modules they depend on or conflict with, and builds a list of what things to build based on the results of the configure script versus the dependency information. It can also be run in an interactive mode (a simple ncurses interface) where you can see what modules depend on and customize what modules gets built.

If for your specific purpose, you only want to build a small set of modules, then you could have a pre-made menuselect.makeopts file that you drop in to the package, and it will only build what you ask for.

Some people really like the system. Others don't like it because it is "non-standard" and this stuff isn't used outside of Asterisk and a couple other packages that we distribute.

But, if the goal is to provide some sort of common build system, while also providing the ability to customize which externals get built, then this may be applicable ...

I am proposing working together to create one build system that can generate custom distros. IEM makes their own custom distros and Pd- extended is basically a custom distro as well. I think we'll all benefit if we share this work. Right now we have multiple parallel and conflicting build systems. I think the asterisk build system has some good examples for what we could do.

.hc

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

You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie

Russell Bryant wrote:

However, going back to the subject of this specific thread, is the move to an svn repository dependent upon resolving this discussion about build systems? There are benefits to making the move, even with the exact same structure and content that exists today. Furthermore, restructuring things in an svn repo is "cheap" and easy, and could easily be done after the move.

What, if anything, must be resolved before someone can move everything to svn?

just yesterday, wini and me brought this up in a discussion. i think we (wine & me) are currently in a state that we don't want any more discussion and still want to switch to SVN.

therefore i propose: we will prepare cvs2svn migration within the next week. the migration will basically do nothing but migrate (no changes within the directory layout), but from my former experiments this does not do 100% cleanly. before the actual migration takes place, the CVS will be closed (read only); after the migration (will probably take about 3hours) and the final import into sourceforge, the SVN will be opened. most stuff should just still work at this point. we will then start to re-organize the directory structure of "our" subtrees

expected timeline: + 4.feb-6.feb: creating migration scripts + tests. + 7.feb: "day of switch"; do the actual migration; on this day no development activity should be made, as changes might be lost otherwise.

eventually, in the days of testing a preview of the repository will be made available as "https://svn.puredata.info/svnroot/pure-data"

if this is ok for everybody, we will just do it.

fgmasdr. IOhannes

On Wed, Jan 30, 2008 at 11:12:13AM +0100, Frank Barknecht wrote:

IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:

...

if this is ok for everybody, we will just do it.

I'm all for it.

Yay, me too!

(waiting for someone to say "...but what about Git/Bazaar/Mercurial?...")

Chris.

------------------- http://mccormick.cx

IOhannes m zmoelnig wrote:

just yesterday, wini and me brought this up in a discussion. i think we (wine & me) are currently in a state that we don't want any more discussion and still want to switch to SVN.

Fine with me ... one thing at a time ...

if this is ok for everybody, we will just do it.

This sounds _great_ to me. Thanks for taking on the move.

-- Russell Bryant

On Wed, 2008-01-30 at 09:59 +0100, IOhannes m zmoelnig wrote:

if this is ok for everybody, we will just do it.

don't know if my vote counts at all, since i don't have write access to cvs, but i am in favor of the move to svn as well.

roman

___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

hi.

happy new year and another round in this oroborus...

Hans-Christoph Steiner wrote:

The Pd-extended build system does this to some degree, but definitely could be improved a lot. Currently if you want to build just one section using a common build system, say sigpack, you can do this:

cvs co pd externals/Makefile externals/sigpack packages/ Makefile.buildlayout cd externals make sigpack && make sigpack_install

now this does not look very cute to me.

or this:

cvs co pd externals/Makefile externals/sigpack packages/ Makefile.buildlayout cd externals/sigpack make && make install

i would prefer something like: cvs co externals/sigpack -d sigpack make -C sigpack install

i still don't see a reason for having ./packages

i don't think that all this does contradict your request for devs not having to worry about their build-system.

i have said this many times before, but do not get tired to re-iterate. for the joys of january, i rephrase it: not having to worry about the build-system does not mean that we have to maintain a centralized monolithic one. what i think, is that the current "build-system for all" is a _first attempt_ in doing it correctly. like so many first attempts, it is basically a dead end.

it cannot be changed because much work has been done to get it as far as it got, and now there is the angst that all the energy would have been spent in vain.

angst is a bad advisor.

nfa,sdr IOhannes

IOhannes m zmölnig wrote:

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.

Yes, I do agree that it makes sense to fit the tool to the desired model of devleopment, and not fit development to the tool ...

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)

Ah, ok. Well, in my opinion, svn:externals works great. I have been using it heavily for the past couple of years with various projects and have not had any problems.

-- Russell

Hans-Christoph Steiner wrote:

I made the "beta-test" comment, I just wanted to know whether it was tried and true before committing to it. I don't really get the advantage of using it. Can you maintain patches against the code that is linked in using svn:externals? A big reason to import the external code is so that you can maintain changes, and to add importing new external releases into those changes. How does that work with svn:externals?

Think of an svn:external as a symbolic link to another repository. So, if you have write access to the repository that you have linked to, then you can do whatever you want. You can not have any changes to that code in your local repository.

The advantage is simply not having multiple copies of the code, so there is less work involved with keeping things in sync. This is best used if you don't maintain any changes to the code in question. If you want to maintain your own changes, then you would either import the code, or have your own branch in the same svn repository where the code lives. Both options involve more work for keeping changes in sync. However, if you have a branch in the same repository, keep your changes there, and link to it via svn:externals, then it is actually very easy to keep the branch in sync with its parent. (I can elaborate if anyone is interested ...)

While svn:externals is certainly handy, it's something to only use where it makes sense. If a certain set of externals is primarily developed elsewhere, then it probably does make sense to use it. But, it comes down to depending on one of two factors:

1) You don't maintain any changes that aren't made in the upstream repository.

or

2) You are able to have your own branch in the upstream repository to maintain your changes.

If neither 1 or 2 is true, then svn:externals does not make sense.

-- Russell Bryant

Am Sonntag, 30. Dezember 2007 11:54 schrieb IOhannes m zmoelnig:

Russell Bryant wrote:

...

While svn:externals is certainly handy, it's something to only use where it makes sense. If a certain set of externals is primarily developed elsewhere, then it probably does make sense to use it. But, it comes down to depending on one of two factors:

1. You don't maintain any changes that aren't made in the upstream

repository.

or

2. You are able to have your own branch in the upstream repository to

maintain your changes.

If neither 1 or 2 is true, then svn:externals does not make sense.

3. the "upstream repository" can really be the same repository.

you can use svn:extenals to re-organize a part of the repository to fit your special needs (e.g. have a flat hierarchy for easy-built in pd-extended)

(you can also do this with "symlinks" (on an svn-level), but i think this makes things more complicated (e.g. you must have checked out the entire tree on filesystems that support symlinks))

Yes in fact this was my intention also, if we build a pd-dist for special projects, we just make a collection of the needed parts with svn:externals either with a special revision of the part or the head, a branch or tag. So it easy for everybody to do so.

mfg winfried ritsch