hi.
after the talk about svn at the pd-con, it seems like there is a general ok from the community, if somebody would be willing to perform the actual migration.
actually i could be this volunteer.
ad miller: there exist migration paths from both cvs and svn to git, so svn would do no harm before we can switch to git :-)
about the structure:
i have written down some ideas on how an svn-repository could be structured at http://puredata.info/Members/zmoelnig/pdcon07/SubVersion
basically the layout keeps the same, but with svn-specifics like meta-directories "trunk", "tags" and "branches". ideally (for me) the layout of "trunk" would be: /trunk/pd/ /trunk/pd-devel/ /trunk/desiredata/ /trunk/externals/ /trunk/packages/ /trunk/scripts/ /trunk/doc/
differences to the current layout are: - moved abstractions&extensions&xgui&Framestein into externals - desiredata&pd-devel live beside "pd" (not in a separate branch) - htdocs is deprecated (but could as well move into "doc") - "supercollider" has moved into scripts (i am not sure about this, but it seems to be the best place, since "bash_completion" is already in there; "supercollider" is no external, it is rather a set of sc3-scripts to ease the use of pd&sc together)
the layout of "tags" would be: /tags/pd-0.40-4/ /tags/pd-0.41-1/ /tags/desiredata-0.39-1/ /tags/zexy-2.1/ /tags/pd-extended-0.39.2-rc1 ... (that is: a _very_ flat structure of "released" code)
the layout of "branches" would be almost the same as that of "tags" (but "tagged" revisions should not be touched any more, whereas "branched" revisions can be bug-fixed...)
both branches/tags should only be used for: - releases (+maintenance) - legacy (discontinued) projects
it is my believe that tags&branches should mainly be used for people who want to checkout "working code" (!), rather than developers who want to try something out without interfering with the existing code-base (trunk)
for quick experimental branches (e.g. if you want to implement a feature but do not want to spill the trunk), i would suggest a 4th meta-directory "experimental", like: /experimental/pd-0.40-kiosk/ /experimental/pd-extended-0.39-newbuildsystem/ projects in "experimental" are not meant to be continued, but their changes should go back into the main trunk (either by merging into the original project or by living besides it) in any case, these experimental branches should be deleted when finished, in order to keep the directory-layour reasonably small.
comments are highly welcome
fgmasd.r IOhannes
Hi, sounds very reasonable to me. The only potential problem that i see is the flat hierarchy (resp. naming scheme) of the branches and tags. It seems that this folder would populate quite fast and might quickly become a mess. On the other hand it's quite easy to clean it up again with svn ;-) Btw., where would the svn repository be located?
greetings, Thomas
Am 11.09.2007 um 16:35 schrieb IOhannes m zmoelnig:
hi.
after the talk about svn at the pd-con, it seems like there is a general ok from the community, if somebody would be willing to perform the actual migration.
actually i could be this volunteer.
ad miller: there exist migration paths from both cvs and svn to git, so svn would do no harm before we can switch to git :-)
about the structure:
i have written down some ideas on how an svn-repository could be structured at http://puredata.info/Members/zmoelnig/pdcon07/SubVersion
basically the layout keeps the same, but with svn-specifics like meta-directories "trunk", "tags" and "branches". ideally (for me) the layout of "trunk" would be: /trunk/pd/ /trunk/pd-devel/ /trunk/desiredata/ /trunk/externals/ /trunk/packages/ /trunk/scripts/ /trunk/doc/
differences to the current layout are:
- moved abstractions&extensions&xgui&Framestein into externals
- desiredata&pd-devel live beside "pd" (not in a separate branch)
- htdocs is deprecated (but could as well move into "doc")
- "supercollider" has moved into scripts (i am not sure about this,
but it seems to be the best place, since "bash_completion" is already in there; "supercollider" is no external, it is rather a set of sc3- scripts to ease the use of pd&sc together)
the layout of "tags" would be: /tags/pd-0.40-4/ /tags/pd-0.41-1/ /tags/desiredata-0.39-1/ /tags/zexy-2.1/ /tags/pd-extended-0.39.2-rc1 ... (that is: a _very_ flat structure of "released" code)
the layout of "branches" would be almost the same as that of "tags" (but "tagged" revisions should not be touched any more, whereas "branched" revisions can be bug-fixed...)
both branches/tags should only be used for:
- releases (+maintenance)
- legacy (discontinued) projects
it is my believe that tags&branches should mainly be used for people who want to checkout "working code" (!), rather than developers who want to try something out without interfering with the existing code-base (trunk)
for quick experimental branches (e.g. if you want to implement a feature but do not want to spill the trunk), i would suggest a 4th meta-directory "experimental", like: /experimental/pd-0.40-kiosk/ /experimental/pd-extended-0.39-newbuildsystem/ projects in "experimental" are not meant to be continued, but their changes should go back into the main trunk (either by merging into the original project or by living besides it) in any case, these experimental branches should be deleted when finished, in order to keep the directory-layour reasonably small.
comments are highly welcome
fgmasd.r IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Thomas Grill wrote:
Hi, sounds very reasonable to me. The only potential problem that i see is the flat hierarchy (resp. naming scheme) of the branches and tags. It seems that this folder would populate quite fast and might quickly become a mess. On the
true. a better idea would probably be that each package gets its folder where releases can be put into, e.g.: /tags/zexy/zexy-2.1/
the reason for the flat hierarchy was, that deep hirarchies often tend to confuse more than not, at least if several unorganized people are involved (like we are): while more scrolling is involved in the flat hierarchy (seemingly more of a mess), inhierarchical structures it might eventually turn out that we have /tags/foo-1.0 but /tags/externals/bar/bar-2.0, which makes bar-2.0 much harder to find in relation to foo-1.0
other hand it's quite easy to clean it up again with svn ;-)
right; even if we do it like A, we can revise the directory structure to B later on :-)
Btw., where would the svn repository be located?
i think there are currently no real objections against staying at sourceforge (at least, i had planned to put it there; just for the sake of all the developers already having an account there (and knowing their passwords))
fmas.dr IOhannes
Am 11.09.2007 um 17:04 schrieb IOhannes m zmoelnig:
Thomas Grill wrote:
Hi, sounds very reasonable to me. The only potential problem that i see is the flat hierarchy (resp. naming scheme) of the branches and tags. It seems that this folder would populate quite fast and might quickly become a mess. On the
true. a better idea would probably be that each package gets its folder where releases can be put into, e.g.: /tags/zexy/zexy-2.1/
the reason for the flat hierarchy was, that deep hirarchies often tend to confuse more than not, at least if several unorganized people are involved (like we are): while more scrolling is involved in the flat hierarchy (seemingly more of a mess), inhierarchical structures it might eventually turn out that we have /tags/foo-1.0 but /tags/externals/bar/bar-2.0, which makes bar-2.0 much harder to find in relation to foo-1.0
Clearly the hierarchy should be as shallow as possible, on the other hand i always like the idea of sandboxes where each of the unorganized people can mess around on a micro-scale, while it stays macroscopically organized. Tags and branches like /tags/project/project-0.0 seem to be a good compromise.
Btw., where would the svn repository be located?
i think there are currently no real objections against staying at sourceforge (at least, i had planned to put it there; just for the sake of all the developers already having an account there (and knowing their passwords))
True, sounds good.
greetings, Thomas
hi again.
this is a subtopic, for those who want to join the discussion on svn.
converting an cvs repository to svn, will create a directory of all branches and tags (that's the way how svn handles branches/tags)
however, i think a lot of these branches do not necessarily need to be imported into an svn-repository, mostly the "initial checkin" branches are totally redundant in my opinion.
here is a list of tags which i think could be deleted without problems:
#TAGS:misc import (htdocs pd-msg aenv~ bsaylor susloop~ svf~ vadsr~ xgui zhzxh~) berforeappmain (packages/darwin_app)
#TAGS:externals flext (flext) HEAD (ggee timestretch vbap vst) initial (hdspm_mixer, sprinkler) KEYBOARDKEYS_0 (keyboardkeys) LIBDIR_0_0 (loaders/libdir, hcs/classpath, hcs/import) PRE-PD-039 (rradical) src_dist (comport) start (externals/build, ekext, packages/darwin_pkg, scripts) TOMSCHOUTEN (pdp) xsample (flext, py, xsample)
#TAGS:pd atl_darwin
here is a list of branches which i think could be deleted without problems:
#BRANCHES:externals abs (iemmatrix) AKA (wiiremote) alexandrequessy (aalex, pdmtl) APPLE (hcs/hid) ASAVITSKY (keyboardkeys) bsaylor (aenv~, bsaylor, susloop~, svf~, vadÃ~, zhzxh~) CHR15M (s-abstractions) d13 (ext13) david_merrill (input_noticer) developername (jasch_lib) doelie (creb, pdp) DOELIE (pdp) edkelly (externals/build, ekext) eighthave (maxlib) fbar (footils, rradical) gg (ggee) HCS (packages/darwin_pk, scripts) iem (iem) iem-ritsch (hdspm_mixer) j (timestretch, vbap) j45ch (boids, detox, jasch_lib) jmmmp (jmmmp) JOHANNES_TAELMAN (smlib) JSARLO (gripd) JUNKLIGHT (mjlib) jusu (vst) krzyszcz (miXed) lukeianninie (mmonoplayer) martin_pi (dfx) MOONIX (moonlib) mrtof (tof) mukau (sprinkler) MUSIL (iemlib) nusmuk (La-kitchen/ nusmuk/ pmpd/) OLAFMATT (maxlib, olafmatt) PIX (nqpoly) postlude (postlude) ritsch (comport) timblech (tb) unlabeled-1.1.1 (grill) vdongen (beatpipe, ff, jackx) x75 (cxc, OSCx) xovo (flext, py, xsample) zmoelnig (ann, hardware, iem, iem16)
#BRANCHES:pd atl_menus dacblocksize jack_0_35_0_cb jack_0_35_0_fifo jsarlo_guipatch jsarlo-guipatch miller tgrill
#BRANCHES:misc # MAIN (?) # pdcvs
lists of all the branches/tags is attached (for those of you who cannot sleep)
mfga.sdr IOhannes
On Tue, 11 Sep 2007, IOhannes m zmoelnig wrote:
this is a subtopic, for those who want to join the discussion on svn. converting an cvs repository to svn, will create a directory of all branches and tags (that's the way how svn handles branches/tags) however, i think a lot of these branches do not necessarily need to be imported into an svn-repository, mostly the "initial checkin" branches are totally redundant in my opinion.
Converting a repository means importing the complete information of the previous repository into the new repository, so that you never need the old repository for any reason whatsoever.
If you want so much to remove existing tags and branches, what is that a sign of? Is SVN appropriate for handling projects that have many tags and branches? What about future branches and tags, will I have to justify them before I create them, so that there aren't too many at once?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Mathieu Bouchard wrote:
On Tue, 11 Sep 2007, IOhannes m zmoelnig wrote:
If you want so much to remove existing tags and branches, what is that a sign of? Is SVN appropriate for handling projects that have many tags and branches?
why should svn be not appropriate for handling projects with many tags/branches? how do my ideas relate to this appropriateness?
my reasoning is, that there are a lot of branches/tags that are useless (in practice), why not getting rid of them when it is possible.
CVS is bad at handling branches/tags, as you cannot really delete them once they are created, and you are forced to create both a tag and a branch when you initially check your code in.
just to clarify this: i want to cleanup the repository before getting it online, within the possibilities of the repository. this means, that all branches/tags will still be available in older revisions of the repository. no information will be lost. but the repository will be cleaned up, awaiting new mess.
What about future branches and tags, will I have to justify them before I create them, so that there aren't too many at once?
says who? what makes you think this? (am i really such control freak?) my point is: changing a repository system implies several changes; we can use these for a major clean-up (the next one might not be before we move to git...)
fma.r IOhannes
On Tue, 11 Sep 2007, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
On Tue, 11 Sep 2007, IOhannes m zmoelnig wrote: If you want so much to remove existing tags and branches, what is that a sign of? Is SVN appropriate for handling projects that have many tags and branches?
why should svn be not appropriate for handling projects with many tags/branches?
I don't know, I deduced that from your willingness to clean things. If SVN itself is perfectly ok with that, is it a problem of user interface? Would you have too often obsolete or irrelevant branch names in your face, in a way that makes you want to hide/remove them as much as possible?
my reasoning is, that there are a lot of branches/tags that are useless (in practice), why not getting rid of them when it is possible.
Because a repository records the complete history of the project, not just that part that you want to keep.
i want to cleanup the repository before getting it online, within the possibilities of the repository. this means, that all branches/tags will still be available in older revisions of the repository. no information will be lost. but the repository will be cleaned up, awaiting new mess.
"Older revisions of the repository"...? So the repository itself needs to be versioned? Will you put the repositories in another, bigger repository? how often you will commit the changes of one to another?
I don't want to ever have to go look in an older repository that is not necessarily online or easily accessible anymore, to figure out information that I have to manually correlate with something that is in the new repository.
What about future branches and tags, will I have to justify them before I create them, so that there aren't too many at once?
says who? what makes you think this? (am i really such control freak?)
No, I'm asking because if you want to reduce the number of branches now, it's to address a problem that you can also continue to address by making sure that all new tags and branches are well-justified... but I don't claim to understand the way you think.
my point is: changing a repository system implies several changes; we can use these for a major clean-up (the next one might not be before we move to git...)
If you have any plans to move to git, you should cancel the plans to move to svn. I really don't want to learn tools that I'll have to relearn again not so long down the road, and I'm sure almost everybody else agrees with that.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On 11 Sep 2007, at 19:10, Mathieu Bouchard wrote:
If you want so much to remove existing tags and branches, what is that a sign of? Is SVN appropriate for handling projects that have many tags and branches? What about future branches and tags, will I have to justify them before I create them, so that there aren't too many at once?
I've seen SVN projects with as dozens of tags/branches. SVN is -far- more efficient and flexible than CVS, IMHO, at managing branching. Justifying a branch is unnecessary. Justifying a tag is trickier if we have a good release manager.
David
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada_______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, 11 Sep 2007, IOhannes m zmoelnig wrote:
hi again.
this is a subtopic, for those who want to join the discussion on svn.
converting an cvs repository to svn, will create a directory of all branches and tags (that's the way how svn handles branches/tags)
however, i think a lot of these branches do not necessarily need to be imported into an svn-repository, mostly the "initial checkin" branches are totally redundant in my opinion.
here is a list of tags which i think could be deleted without problems:
#TAGS:misc import (htdocs pd-msg aenv~ bsaylor susloop~ svf~ vadsr~ xgui zhzxh~)
These tags are useful for handling imported code that is maintained elsewhere. Does SVN handle this differently?
berforeappmain (packages/darwin_app)
#TAGS:externals flext (flext) HEAD (ggee timestretch vbap vst) initial (hdspm_mixer, sprinkler) KEYBOARDKEYS_0 (keyboardkeys) LIBDIR_0_0 (loaders/libdir, hcs/classpath, hcs/import) PRE-PD-039 (rradical) src_dist (comport) start (externals/build, ekext, packages/darwin_pkg, scripts) TOMSCHOUTEN (pdp) xsample (flext, py, xsample)
#TAGS:pd atl_darwin
here is a list of branches which i think could be deleted without problems:
#BRANCHES:externals abs (iemmatrix) AKA (wiiremote)
again, this is because I am tracking external code, this is one of the things that branches help with.
alexandrequessy (aalex, pdmtl) APPLE (hcs/hid)
ditto
ASAVITSKY (keyboardkeys) bsaylor (aenv~, bsaylor, susloop~, svf~, vadß~, zhzxh~)
ditto
There are more like this. Purging tags could be a tricky proposition. I think the purge list should be opt-in rather than opt-out to prevent losing important data.
.hc
CHR15M (s-abstractions) d13 (ext13) david_merrill (input_noticer) developername (jasch_lib) doelie (creb, pdp) DOELIE (pdp) edkelly (externals/build, ekext) eighthave (maxlib) fbar (footils, rradical) gg (ggee) HCS (packages/darwin_pk, scripts) iem (iem) iem-ritsch (hdspm_mixer) j (timestretch, vbap) j45ch (boids, detox, jasch_lib) jmmmp (jmmmp) JOHANNES_TAELMAN (smlib) JSARLO (gripd) JUNKLIGHT (mjlib) jusu (vst) krzyszcz (miXed) lukeianninie (mmonoplayer) martin_pi (dfx) MOONIX (moonlib) mrtof (tof) mukau (sprinkler) MUSIL (iemlib) nusmuk (La-kitchen/ nusmuk/ pmpd/) OLAFMATT (maxlib, olafmatt) PIX (nqpoly) postlude (postlude) ritsch (comport) timblech (tb) unlabeled-1.1.1 (grill) vdongen (beatpipe, ff, jackx) x75 (cxc, OSCx) xovo (flext, py, xsample) zmoelnig (ann, hardware, iem, iem16)
#BRANCHES:pd atl_menus dacblocksize jack_0_35_0_cb jack_0_35_0_fifo jsarlo_guipatch jsarlo-guipatch miller tgrill
#BRANCHES:misc # MAIN (?) # pdcvs
lists of all the branches/tags is attached (for those of you who cannot sleep)
mfga.sdr IOhannes
zen \ \ \[D[D[D[D
Hans-Christoph Steiner wrote:
#TAGS:misc import (htdocs pd-msg aenv~ bsaylor susloop~ svf~ vadsr~ xgui zhzxh~)
These tags are useful for handling imported code that is maintained elsewhere.
thats what the documentation says. have you ever made any use of the "useful" thing?
Does SVN handle this differently?
yes and now. yes: you don't _have_ to create a tag and a branch whenever you import code. no: you can import code that is maintained elsewhere into a branch, a tag, the trunk (or just any other directory) yes: svn is able to handle references to external (svn!)repositories (which imo is better than blindly importing anything useful)
so the answer is: you can do it like you did in cvs, but you can handle it more appropriate at your own judgement.
There are more like this. Purging tags could be a tricky proposition. I think the purge list should be opt-in rather than opt-out to prevent losing important data.
well yes, i would agree. but who remembers that there was a "dacblocksize" branch of pd? who works on this? will there ever be work done on this again? (fyi: "dacblocksize" is a branch i have made; the purpose of the branch has been reached (although the code never made it into pd); i have not worked on it for some years; i have no plans to work on it ever again (and if i did, i would have to start from the beginning anyhow); i have plainly forgotten that this branch ever existed; i would love to see it deleted)
i hope that (more) people read more carefully in an opt-out process. (even though it could be really handled as an opt-in)
finally, did i say "purging"? i should have said "deleting" (within the version control system, rather than purging outside it); no data will be lost: you can always go back to an older revision to retrieve the data)
fmga.sdr IOhannes
Hallo, yes. The appropriate way to handle this IMO is to do the initial conversion (thus creating the many directories), then do an svn rm for those tags that are abandoned or unnecessary. Tags and Branches in SVN are great because they can have lifetimes - you can make your branch to try some things out, merge it and then delete the branch. I do this all the time, it's very handy. You can always svn copy from a previous revision to resurrect these "deleted" tags and branches, so returning to the old CVS will not be necessary.
(also, IOhannes, I apologize for not replying to your previous inquiry! I've been blindsided by work in the past months.)
On 9/12/07, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Hans-Christoph Steiner wrote:
#TAGS:misc import (htdocs pd-msg aenv~ bsaylor susloop~ svf~ vadsr~ xgui zhzxh~)
These tags are useful for handling imported code that is maintained elsewhere.
thats what the documentation says. have you ever made any use of the "useful" thing?
Does SVN handle this differently?
yes and now. yes: you don't _have_ to create a tag and a branch whenever you import code. no: you can import code that is maintained elsewhere into a branch, a tag, the trunk (or just any other directory) yes: svn is able to handle references to external (svn!)repositories (which imo is better than blindly importing anything useful)
so the answer is: you can do it like you did in cvs, but you can handle it more appropriate at your own judgement.
There are more like this. Purging tags could be a tricky proposition. I think the purge list should be opt-in rather than opt-out to prevent losing important data.
well yes, i would agree. but who remembers that there was a "dacblocksize" branch of pd? who works on this? will there ever be work done on this again? (fyi: "dacblocksize" is a branch i have made; the purpose of the branch has been reached (although the code never made it into pd); i have not worked on it for some years; i have no plans to work on it ever again (and if i did, i would have to start from the beginning anyhow); i have plainly forgotten that this branch ever existed; i would love to see it deleted)
i hope that (more) people read more carefully in an opt-out process. (even though it could be really handled as an opt-in)
finally, did i say "purging"? i should have said "deleting" (within the version control system, rather than purging outside it); no data will be lost: you can always go back to an older revision to retrieve the data)
fmga.sdr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Sep 12, 2007, at 4:22 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
#TAGS:misc import (htdocs pd-msg aenv~ bsaylor susloop~ svf~ vadsr~ xgui zhzxh~)
These tags are useful for handling imported code that is maintained elsewhere.
thats what the documentation says. have you ever made any use of the "useful" thing?
Yes, I've used it to track Tom Schouten's changes to PDP, for example.
Does SVN handle this differently?
yes and now. yes: you don't _have_ to create a tag and a branch whenever you import code. no: you can import code that is maintained elsewhere into a branch, a tag, the trunk (or just any other directory) yes: svn is able to handle references to external (svn!) repositories (which imo is better than blindly importing anything useful)
That sounds horrendous to me, then you are forced to track their changes. Could you imagine if we tracked portaudio like that with Pd? We'd spent half our dev time fixing breakage caused by portaudio changes. It's a very useful thing to keep code static until you are ready for change.
so the answer is: you can do it like you did in cvs, but you can handle it more appropriate at your own judgement.
There are more like this. Purging tags could be a tricky proposition. I think the purge list should be opt-in rather than opt-out to prevent losing important data.
well yes, i would agree. but who remembers that there was a "dacblocksize" branch of pd? who works on this? will there ever be work done on this again? (fyi: "dacblocksize" is a branch i have made; the purpose of the branch has been reached (although the code never made it into pd); i have not worked on it for some years; i have no plans to work on it ever again (and if i did, i would have to start from the beginning anyhow); i have plainly forgotten that this branch ever existed; i would love to see it deleted)
That's why I think opt-in is key. I don't think just because people can't rememeber at the moment what something is used for, it should be deleted. But if you know what it is, and that it should go, then delete it.
.hc
i hope that (more) people read more carefully in an opt-out process. (even though it could be really handled as an opt-in)
finally, did i say "purging"? i should have said "deleting" (within the version control system, rather than purging outside it); no data will be lost: you can always go back to an older revision to retrieve the data)
fmga.sdr IOhannes
------------------------------------------------------------------------ ----
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
Does SVN handle this differently?
yes and now. yes: you don't _have_ to create a tag and a branch whenever you import code. no: you can import code that is maintained elsewhere into a branch, a tag, the trunk (or just any other directory) yes: svn is able to handle references to external (svn!) repositories (which imo is better than blindly importing anything useful)
That sounds horrendous to me, then you are forced to track their changes. Could you imagine if we tracked portaudio like that with Pd? We'd spent half our dev time fixing breakage caused by portaudio changes. It's a very useful thing to keep code static until you are ready for change.
You can set a specific revision to reference, so that this does not happen.
A cool thing I've been doing recently with the externals feature is using them more like symlinks; so for portaudio you can put the revision you want to stay static in a central location (e.g. /svnexternals/portaudio) and then set /that/ as the external directory. That way you still have a single copy, but it is replicated to everywhere it is needed.
Cheers Luke
On Sep 13, 2007, at 12:06 AM, Luke Iannini (pd) wrote:
Does SVN handle this differently?
yes and now. yes: you don't _have_ to create a tag and a branch whenever you import code. no: you can import code that is maintained elsewhere into a branch, a tag, the trunk (or just any other directory) yes: svn is able to handle references to external (svn!) repositories (which imo is better than blindly importing anything useful)
That sounds horrendous to me, then you are forced to track their changes. Could you imagine if we tracked portaudio like that with Pd? We'd spent half our dev time fixing breakage caused by portaudio changes. It's a very useful thing to keep code static until you are ready for change.
You can set a specific revision to reference, so that this does not happen.
A cool thing I've been doing recently with the externals feature is using them more like symlinks; so for portaudio you can put the revision you want to stay static in a central location ( e.g. / svnexternals/portaudio) and then set /that/ as the external directory. That way you still have a single copy, but it is replicated to everywhere it is needed.
How well does this really work in production? It's really pretty easy to import code into repositories and manage it there. The idea is cool, but I am not really up for beta testing svn features. There are plenty of Pd bugs to deal with :D. This import feature has been around for 10+ years in CVS at least.
.hc
Cheers Luke
------------------------------------------------------------------------ ----
kill your television
Well, we have been using that feature in production in our web-startup for over a year and a half, if it is any consolation? Why do you say it is "beta-testing"? SVN is not exactly a bleeding edge technology at this point ; ); the externals feature has been there since at least 2002 judging by the changelog. Cheers Luke
On 9/13/07, Hans-Christoph Steiner hans@eds.org wrote:
On Sep 13, 2007, at 12:06 AM, Luke Iannini (pd) wrote:
Does SVN handle this differently?
yes and now. yes: you don't _have_ to create a tag and a branch whenever you import code. no: you can import code that is maintained elsewhere into a branch, a tag, the trunk (or just any other directory) yes: svn is able to handle references to external (svn!) repositories (which imo is better than blindly importing anything useful)
That sounds horrendous to me, then you are forced to track their changes. Could you imagine if we tracked portaudio like that with Pd? We'd spent half our dev time fixing breakage caused by portaudio changes. It's a very useful thing to keep code static until you are ready for change.
You can set a specific revision to reference, so that this does not happen.
A cool thing I've been doing recently with the externals feature is using them more like symlinks; so for portaudio you can put the revision you want to stay static in a central location ( e.g. /svnexternals/portaudio) and then set /that/ as the external directory. That way you still have a single copy, but it is replicated to everywhere it is needed.
How well does this really work in production? It's really pretty easy to import code into repositories and manage it there. The idea is cool, but I am not really up for beta testing svn features. There are plenty of Pd bugs to deal with :D. This import feature has been around for 10+ years in CVS at least.
.hc
Cheers Luke
kill your television
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info http://lists.puredata.info/listinfo/pd-dev /listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev
On 13 Sep 2007, at 16:08, Hans-Christoph Steiner wrote:
A cool thing I've been doing recently with the externals feature is using them more like symlinks; so for portaudio you can put the revision you want to stay static in a central location ( e.g. / svnexternals/portaudio) and then set /that/ as the external directory. That way you still have a single copy, but it is replicated to everywhere it is needed.
How well does this really work in production? It's really pretty easy to import code into repositories and manage it there. The idea is cool, but I am not really up for beta testing svn features. There are plenty of Pd bugs to deal with :D. This import feature has been around for 10+ years in CVS at least.
I think it's robust enough, but in practice (in _my_ practice), it can get hard to keep track of them, and I end up doing a lot of svnlook
d
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
about the structure:
i have written down some ideas on how an svn-repository could be structured at http://puredata.info/Members/zmoelnig/pdcon07/SubVersion
basically the layout keeps the same, but with svn-specifics like meta-directories "trunk", "tags" and "branches". ideally (for me) the layout of "trunk" would be: /trunk/pd/ /trunk/pd-devel/ /trunk/desiredata/ /trunk/externals/ /trunk/packages/ /trunk/scripts/ /trunk/doc/
Another possibility that is seen sometimes in svn-repositories would be this:
/pd/trunk/ /pd/tags/ /pd/branches/ ... /doc/trunk/ /doc/tags/ /doc/branches/
I just want to mention this, I didn't contemplate dis/advantages of this one vs. your suggestion at all so far.
differences to the current layout are:
- moved abstractions&extensions&xgui&Framestein into externals
Good, KISS.
Ciao
On Tue, 11 Sep 2007, IOhannes m zmoelnig wrote:
- moved abstractions&extensions&xgui&Framestein into externals
good thing, as long as "abstractions" does not become a subfolder of "externals"... but I would rather have it under a common name that isn't "abstractions" nor "externals".
I suppose that "xgui" and "Framestein" retain their folder, whereas "abstractions", "externals", "extensions" contents are merged together.
- desiredata&pd-devel live beside "pd" (not in a separate branch)
If Thomas hasn't changed his mind, pd-devel is going to be obsolete soon. The latest changes still have to be picked up from there and moved somewhere else, such as sf.net patchtracker and the desiredata branch, but for all practical purposes, there will be no such branch. Let me also say that pd-devel very much deserves to be a branch (rather than a plain folder) because it has rather high mergeability with Miller's branch.
In contrast, for the new DesireData (since dec.2006), I no longer attempt mergeability of any part of it. There's no future goal of keeping any part of the code in sync with pd for any reason whatsoever. All the sync necessary is to be done using automated tests (no matter how much work that is, it's worth it)
- "supercollider" has moved into scripts (i am not sure about this, but
it seems to be the best place, since "bash_completion" is already in there; "supercollider" is no external, it is rather a set of sc3-scripts to ease the use of pd&sc together)
"scripts" is a vague name I'd get rid of. Also, "gripd" contains a high ratio of non-"abstraction", non-"external" files. I don't know whether this ought to be taken into account when categorising projects...
both branches/tags should only be used for:
- releases (+maintenance)
- legacy (discontinued) projects
for quick experimental branches (e.g. if you want to implement a feature but do not want to spill the trunk), i would suggest a 4th meta-directory "experimental", like: /experimental/pd-0.40-kiosk/
I don't know why you want this. You say what people should do according to yourself, but you don't explain what's your motivation for it.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Am 11.09.2007 um 19:58 schrieb Mathieu Bouchard:
- desiredata&pd-devel live beside "pd" (not in a separate branch)
If Thomas hasn't changed his mind, pd-devel is going to be obsolete soon. The latest changes still have to be picked up from there and moved somewhere else, such as sf.net patchtracker and the desiredata branch, but for all practical purposes, there will be no such branch. Let me also say that pd-devel very much deserves to be a branch (rather than a plain folder) because it has rather high mergeability with Miller's branch.
No, i haven't, but i have no idea how long it will take to extract all of the good ideas in pd-devel and make patches for that. Right now i haven't had time to only make a single one, although that will most likely change soon. I'm not sure whether it's better to have pd-devel as a stand-alone project or let it be a branch... it doesn't seems to really matter. About the mergeability i'm not so positive... i'm afraid the only way to really promote the change to pd-main is to hand-craft the patches.
greetings, Thomas
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
If Thomas hasn't changed his mind, pd-devel is going to be obsolete soon. The latest changes still have to be picked up from there and moved somewhere else, such as sf.net patchtracker and the desiredata branch, but for all practical purposes, there will be no such branch. Let me also say that pd-devel very much deserves to be a branch (rather than a plain folder) because it has rather high mergeability with Miller's branch.
Branches (and tags) in Subversion *are* plain folders:
"Creating a branch is very simple - you make a copy of the project in the repository using the svn copy command."
See chapter 4 of the subversion book: http://svnbook.red-bean.com/en/1.4/svn.branchmerge.using.html subsection "Creating a branch" and the rest of that chapter as well.
"scripts" is a vague name I'd get rid of.
Or make it even more vague and call it "misc", so gripd would feel at home there as well.
Ciao
Mathieu Bouchard wrote:
On Tue, 11 Sep 2007, IOhannes m zmoelnig wrote:
- moved abstractions&extensions&xgui&Framestein into externals
good thing, as long as "abstractions" does not become a subfolder of "externals"... but I would rather have it under a common name that isn't "abstractions" nor "externals".
I suppose that "xgui" and "Framestein" retain their folder, whereas "abstractions", "externals", "extensions" contents are merged together.
this is basically correct: ./Framestein will become externals/Framestein ./abstractions/purepd/ will become ./externals/purepd ./abstractions/footils/list-abs will become ./externals/footils/list-abs
- desiredata&pd-devel live beside "pd" (not in a separate branch)
If Thomas hasn't changed his mind, pd-devel is going to be obsolete soon. The latest changes still have to be picked up from there and moved somewhere else, such as sf.net patchtracker and the desiredata branch, but for all practical purposes, there will be no such branch. Let me also say that pd-devel very much deserves to be a branch (rather than a plain folder) because it has rather high mergeability with Miller's branch.
yes this fits perfectly into my layout: once pd-devel is abandoned by all active developers (this is: thomas), the folder will be _moved_ from ./trunk/pd-devel to ./tags/pd-devel/pd-devel-<versionnumber (or the like) all the revision history will stay intact while at the same time, nobody has to care about a "dead" pd-devel laying around in the trunk. if, at some point, somebody desides to re-start pd-devel (not that i think somebody would; but just as a theoretical example), the latest folder (from which one would like to start) would be _copied_ to the trunk.
In contrast, for the new DesireData (since dec.2006), I no longer attempt mergeability of any part of it. There's no future goal of keeping any part of the code in sync with pd for any reason whatsoever. All the sync necessary is to be done using automated tests (no matter how much work that is, it's worth it)
that is exactly why i do think that folders are so much better than tags. currently, "desiredata" is a branch of "pd", implying a common code-base. a folder is just a folder, it doesn't imply very much. i believe that putting "desiredata" besides "pd" gives both of them a kind of "equality".
- "supercollider" has moved into scripts (i am not sure about this, but
it seems to be the best place, since "bash_completion" is already in there; "supercollider" is no external, it is rather a set of sc3-scripts to ease the use of pd&sc together)
"scripts" is a vague name I'd get rid of. Also, "gripd" contains a high ratio of non-"abstraction", non-"external" files. I don't know whether this ought to be taken into account when categorising projects...
most stuff in "scripts" currently are "scripts". "supercollider" would not necessarily fit in there ("bash_completion" is not a script either, that's what made me think of that) probably we should just create a new category "misc" _besides_ "scripts", and put both "supercollider" and "bash_completion" (and probably "gripd" in there)
both branches/tags should only be used for:
- releases (+maintenance)
- legacy (discontinued) projects
for quick experimental branches (e.g. if you want to implement a feature but do not want to spill the trunk), i would suggest a 4th meta-directory "experimental", like: /experimental/pd-0.40-kiosk/
I don't know why you want this. You say what people should do according to yourself, but you don't explain what's your motivation for it.
my motivation behind all this is to keep it simple on the long run. however, i admit that this motivation might lead to over-complicated plans (which is bad). otoh, i think if there are some "guidelines" on where to put stuff, i guess people might happily accept them (even if these guidelines might seem to be sub-optimal on the first glance). finally, a suggestion implies discussion: i do not say what people should do according to myself, but i rather ask them whether they would like to do it "my way"; this is a difference
btw, i find it herzerfrischend that you so readily discovered that there are only my projects in my proposal of an experimental folder.
fmga.r IOhannes
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, 11 Sep 2007, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
On Tue, 11 Sep 2007, IOhannes m zmoelnig wrote:
- moved abstractions&extensions&xgui&Framestein into externals
good thing, as long as "abstractions" does not become a subfolder of "externals"... but I would rather have it under a common name that isn't "abstractions" nor "externals".
I suppose that "xgui" and "Framestein" retain their folder, whereas "abstractions", "externals", "extensions" contents are merged together.
this is basically correct: ./Framestein will become externals/Framestein ./abstractions/purepd/ will become ./externals/purepd ./abstractions/footils/list-abs will become ./externals/footils/list-abs
Sounds good, how about downcasing while you are at it, so we have it more standardized.
Plus, what about adding Gem back to the main pure-data repository?
All these changes will cause major breakage to the Pd-extended build system, anyone want to help fix it? :D
.hc
- desiredata&pd-devel live beside "pd" (not in a separate branch)
If Thomas hasn't changed his mind, pd-devel is going to be obsolete soon. The latest changes still have to be picked up from there and moved somewhere else, such as sf.net patchtracker and the desiredata branch, but for all practical purposes, there will be no such branch. Let me also say that pd-devel very much deserves to be a branch (rather than a plain folder) because it has rather high mergeability with Miller's branch.
yes this fits perfectly into my layout: once pd-devel is abandoned by all active developers (this is: thomas), the folder will be _moved_ from ./trunk/pd-devel to ./tags/pd-devel/pd-devel-<versionnumber (or the like) all the revision history will stay intact while at the same time, nobody has to care about a "dead" pd-devel laying around in the trunk. if, at some point, somebody desides to re-start pd-devel (not that i think somebody would; but just as a theoretical example), the latest folder (from which one would like to start) would be _copied_ to the trunk.
In contrast, for the new DesireData (since dec.2006), I no longer attempt mergeability of any part of it. There's no future goal of keeping any part of the code in sync with pd for any reason whatsoever. All the sync necessary is to be done using automated tests (no matter how much work that is, it's worth it)
that is exactly why i do think that folders are so much better than tags. currently, "desiredata" is a branch of "pd", implying a common code-base. a folder is just a folder, it doesn't imply very much. i believe that putting "desiredata" besides "pd" gives both of them a kind of "equality".
- "supercollider" has moved into scripts (i am not sure about this, but
it seems to be the best place, since "bash_completion" is already in there; "supercollider" is no external, it is rather a set of sc3-scripts to ease the use of pd&sc together)
"scripts" is a vague name I'd get rid of. Also, "gripd" contains a high ratio of non-"abstraction", non-"external" files. I don't know whether this ought to be taken into account when categorising projects...
most stuff in "scripts" currently are "scripts". "supercollider" would not necessarily fit in there ("bash_completion" is not a script either, that's what made me think of that) probably we should just create a new category "misc" _besides_ "scripts", and put both "supercollider" and "bash_completion" (and probably "gripd" in there)
both branches/tags should only be used for:
- releases (+maintenance)
- legacy (discontinued) projects
for quick experimental branches (e.g. if you want to implement a feature but do not want to spill the trunk), i would suggest a 4th meta-directory "experimental", like: /experimental/pd-0.40-kiosk/
I don't know why you want this. You say what people should do according to yourself, but you don't explain what's your motivation for it.
my motivation behind all this is to keep it simple on the long run. however, i admit that this motivation might lead to over-complicated plans (which is bad). otoh, i think if there are some "guidelines" on where to put stuff, i guess people might happily accept them (even if these guidelines might seem to be sub-optimal on the first glance). finally, a suggestion implies discussion: i do not say what people should do according to myself, but i rather ask them whether they would like to do it "my way"; this is a difference
btw, i find it herzerfrischend that you so readily discovered that there are only my projects in my proposal of an experimental folder.
fmga.r IOhannes
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
zen \ \ \[D[D[D[D
Hans-Christoph Steiner wrote:
Sounds good, how about downcasing while you are at it, so we have it more standardized.
i don't see a real benefit from it. but then: why not? (and finally: since Framestein is really abandoned for some years, i would remove it from the /trunk/ anyhow and keep it living in "/tags/framestein/"
Plus, what about adding Gem back to the main pure-data repository?
why?
All these changes will cause major breakage to the Pd-extended build system, anyone want to help fix it? :D
(please skip to the bottom if you don't want to read that again)
the joys of monolithic build-systems...
however, once we have moved to SVN i would like to make an experimental branch of pd-extended to re-work the entire build-system into small (managable) pieces that are modular and survive directory re-structuring. i know that you are not really interested in that, but probably others are :-)
fmg.ad IOhannes
On Sep 12, 2007, at 4:07 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Sounds good, how about downcasing while you are at it, so we have it more standardized.
i don't see a real benefit from it. but then: why not? (and finally: since Framestein is really abandoned for some years, i would remove it from the /trunk/ anyhow and keep it living in "/ tags/framestein/"
Plus, what about adding Gem back to the main pure-data repository?
why?
- everything else is in that repository - makes for one checkout for everything - makes it easy to make branches and tags for the whole shebang - we are one big happy family :D
All these changes will cause major breakage to the Pd-extended build system, anyone want to help fix it? :D
(please skip to the bottom if you don't want to read that again)
the joys of monolithic build-systems...
however, once we have moved to SVN i would like to make an experimental branch of pd-extended to re-work the entire build- system into small (managable) pieces that are modular and survive directory re-structuring. i know that you are not really interested in that, but probably others are :-)
I am all for improving things, but it seems that this would need to happen before reorganizing the repository. Otherwise we are without pd-extended builds until it happens. That's not why I spent all my free time one summer building the Pd-extended and the auto-build farm. Switching to SVN is not a good enough reason for major breakage.
.hc
fmg.ad IOhannes
------------------------------------------------------------------------ ----
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Hans-Christoph Steiner wrote:
Plus, what about adding Gem back to the main pure-data repository?
why?
- everything else is in that repository
?
- makes for one checkout for everything
see my random mentions of svn:externals
- makes it easy to make branches and tags for the whole shebang
see my random mentions of svn:externals
- we are one big happy family :D
true, we love each other but does this mean we have to live in the same house?
mfga.sdr IOhannes
Hans-Christoph Steiner wrote:
however, once we have moved to SVN i would like to make an experimental branch of pd-extended to re-work the entire build-system into small (managable) pieces that are modular and survive directory re-structuring. i know that you are not really interested in that, but probably others are :-)
I am all for improving things, but it seems that this would need to happen before reorganizing the repository.
doing this in an svn repository will be so much more easy.
Otherwise we are without pd-extended builds until it happens.
no not quite true. 1st of all, all the /externals would be compiled as usual. (nothing changes here, just some things get added) however /abstractions would be left out of pd-extended at first. then you could just move the abstractions/Makefile as a temporary hack to externals/Makefile.abstractions and call that from externals/Makefile (the same with other stuff, which i am currently unaware that it is in pd-extended: e.g. gripd(?))
this should be doable in one afternoon.
That's not why I spent all my free time one summer building the Pd-extended and the auto-build farm. Switching to SVN is not a good enough reason for major breakage.
i see your point. that is why i always opposed to a monolithic non-scalable build-system: it makes refactoring hard if not impossible.
fmasdr. IOhannes
On Sep 13, 2007, at 5:07 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
however, once we have moved to SVN i would like to make an experimental branch of pd-extended to re-work the entire build- system into small (managable) pieces that are modular and survive directory re-structuring. i know that you are not really interested in that, but probably others are :-)
I am all for improving things, but it seems that this would need to happen before reorganizing the repository.
doing this in an svn repository will be so much more easy.
Otherwise we are without pd-extended builds until it happens.
no not quite true. 1st of all, all the /externals would be compiled as usual. (nothing changes here, just some things get added) however /abstractions would be left out of pd-extended at first. then you could just move the abstractions/Makefile as a temporary hack to externals/Makefile.abstractions and call that from externals/Makefile (the same with other stuff, which i am currently unaware that it is in pd-extended: e.g. gripd(?))
this should be doable in one afternoon.
That's not why I spent all my free time one summer building the Pd- extended and the auto-build farm. Switching to SVN is not a good enough reason for major breakage.
i see your point. that is why i always opposed to a monolithic non- scalable build-system: it makes refactoring hard if not impossible.
Does that mean you are volunteering to do the work? :-D About the technical issues, we are on the same page, more or less. I am just really burnt out on build system issues.
.hc
fmasdr. IOhannes
------------------------------------------------------------------------ ----
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
On Sep 13, 2007, at 5:07 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
however, once we have moved to SVN i would like to make an experimental branch of pd-extended to re-work the entire build- system into small (managable) pieces that are modular and survive directory re-structuring. i know that you are not really interested in that, but probably others are :-)
I am all for improving things, but it seems that this would need to happen before reorganizing the repository.
doing this in an svn repository will be so much more easy.
Otherwise we are without pd-extended builds until it happens.
no not quite true. 1st of all, all the /externals would be compiled as usual. (nothing changes here, just some things get added) however /abstractions would be left out of pd-extended at first. then you could just move the abstractions/Makefile as a temporary hack to externals/Makefile.abstractions and call that from externals/Makefile (the same with other stuff, which i am currently unaware that it is in pd-extended: e.g. gripd(?))
this should be doable in one afternoon.
That's not why I spent all my free time one summer building the Pd- extended and the auto-build farm. Switching to SVN is not a good enough reason for major breakage.
i see your point. that is why i always opposed to a monolithic non- scalable build-system: it makes refactoring hard if not impossible.
One last comment on this topic: since SVN is supposed to handle moves so well, why don't we defer the very contensious issues of reogranizing the directories and tags/branches until after we have the SVN repository working nicely? It seems that it is too much to deal with all at once via email.
Also, that makes me think that there should be a (IRC?) meeting about the move to SVN first, then later about reorganizing.
.hc
fmasdr. IOhannes
------------------------------------------------------------------------ ----
There is no way to peace, peace is the way. -A.J. Muste
On 14 Sep 2007, at 05:23, Hans-Christoph Steiner wrote:
One last comment on this topic: since SVN is supposed to handle moves so well, why don't we defer the very contensious issues of reogranizing the directories and tags/branches until after we have the SVN repository working nicely? It seems that it is too much to deal with all at once via email.
because it is perfectly possible to have both cvs and svn on SF in the same project, this works and means we can apply lazy consensus to IOhannes simply tidying up after posting something like 'I'm about to can the following', which is great, so I agree. Plus, some of us feel much more confident working in SVN so we'd be able to help more at the nasty build-system end (here's hoping).
Also, that makes me think that there should be a (IRC?) meeting about the move to SVN first, then later about reorganizing
throw some dates around?
David
.hc
fmasdr. IOhannes
--
There is no way to peace, peace is the way. -A.J. Muste
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Sep 17, 2007, at 4:50 PM, David Plans Casal wrote:
On 14 Sep 2007, at 05:23, Hans-Christoph Steiner wrote:
One last comment on this topic: since SVN is supposed to handle moves so well, why don't we defer the very contensious issues of reogranizing the directories and tags/branches until after we have the SVN repository working nicely? It seems that it is too much to deal with all at once via email.
because it is perfectly possible to have both cvs and svn on SF in the same project, this works and means we can apply lazy consensus to IOhannes simply tidying up after posting something like 'I'm about to can the following', which is great, so I agree. Plus, some of us feel much more confident working in SVN so we'd be able to help more at the nasty build-system end (here's hoping).
I think that's a lot to risk on hope. I think people are enjoying regular, usable, reasonably complete builds. I'd like to keep that going, so I think we need to have someone committed to fixing the build system breakage before we break it. That's not going to be me in the near future, but of course, I'd help out if someone leads the charge.
Also, that makes me think that there should be a (IRC?) meeting about the move to SVN first, then later about reorganizing
throw some dates around?
Move to SVN now, work that out, then start talking reorg. But IOhannes is the lead on the SVN move, so that's just my two cents.
.hc
David
.hc
fmasdr. IOhannes
--
There is no way to peace, peace is the way. -A.J. Muste
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
If you are not part of the solution, you are part of the problem.
On 11/09/2007, at 19.58, Mathieu Bouchard wrote:
On Tue, 11 Sep 2007, IOhannes m zmoelnig wrote:
- moved abstractions&extensions&xgui&Framestein into externals
good thing (snip) but I would rather have it under a common name that isn't "abstractions" nor "externals".
I don't know if i have a say, but I agree. What could it be? Extra, addons, cpdan?
I subscribe to KISS too btw.
Steffen wrote:
On 11/09/2007, at 19.58, Mathieu Bouchard wrote:
On Tue, 11 Sep 2007, IOhannes m zmoelnig wrote:
- moved abstractions&extensions&xgui&Framestein into externals
good thing (snip) but I would rather have it under a common name that isn't "abstractions" nor "externals".
personally i think "externals" is exactly the name: it means "pd stuff that does not come with pd itself", rather than "pd-objects written in C"
i would narrow the definition to "pd-objects not internal to pd", but this is just an arbitrary decision of mine.
mf.asdr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
personally i think "externals" is exactly the name: it means "pd stuff that does not come with pd itself", rather than "pd-objects written in C"
How about "extensions"? Somehow the word "externals" has sunken in as meaning binary externals written in C/C++ and "abstractions" are Pd patches and we don't have a word yet for non-compiled object written in Python etc. so "extensions" could grab all of these together without a need to change the words we're used to.
Ciao
On 12/09/2007, at 20.50, Frank Barknecht wrote:
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
personally i think "externals" is exactly the name: it means "pd stuff that does not come with pd itself", rather than "pd-objects written in C"
How about "extensions"? Somehow the word "externals" has sunken in as meaning binary externals written in C/C++ and "abstractions" are Pd patches and we don't have a word yet for non-compiled object written in Python etc. so "extensions" could grab all of these together without a need to change the words we're used to.
By the best of intentions -- I think that's a nice 'bike shed' colour.
best, steffen
On Wed, Sep 12, 2007 at 10:08:27PM +0200, Steffen wrote:
On 12/09/2007, at 20.50, Frank Barknecht wrote:
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
personally i think "externals" is exactly the name: it means "pd stuff that does not come with pd itself", rather than "pd-objects written in C"
How about "extensions"? Somehow the word "externals" has sunken in as meaning binary externals written in C/C++ and "abstractions" are Pd patches and we don't have a word yet for non-compiled object written in Python etc. so "extensions" could grab all of these together without a need to change the words we're used to.
By the best of intentions -- I think that's a nice 'bike shed' colour.
I am not sure I understand what you mean by this Steffen, but I think that I agree with Frank here that it's a really good idea to have a word that we can use that encompasses "externals", "abstractions", and anything else that can be instantiated as an object in Pd, and that "extensions" is a great name for that. I would be loathe to call them all 'externals' since as Frank says, that name is generally reserved for compiled extensions to the Pd object set and would become really confusing really quickly. In short; I'd like to be a disciple in Roman's church of consistency. :)
Best,
Chris.
------------------- http://mccormick.cx
On 13/09/2007, at 17.05, Chris McCormick wrote:
On Wed, Sep 12, 2007 at 10:08:27PM +0200, Steffen wrote:
On 12/09/2007, at 20.50, Frank Barknecht wrote:
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
personally i think "externals" is exactly the name (snip)
How about "extensions"? (snip)
By the best of intentions -- I think that's a nice 'bike shed' colour.
I am not sure I understand what you mean by this Steffen (snip)
I'm sorry that i was not clear.
I mean first of all, that extensions is a ok with me. I before stated (agreed with Mathieu) that it would be nice if the union of parts was not named the same as one of the parts.
Secondly -- this is were the best of intentions and 'bike shed' comes in -- i meant to (indirectly) expressed a concern wrt. the discussion about the transition, as it reminds me of the 'bike shed colour' story. I would like to underline the 'best of intentions' part!
Best, Steffen
On Sep 12, 2007, at 4:02 AM, IOhannes m zmoelnig wrote:
Steffen wrote:
On 11/09/2007, at 19.58, Mathieu Bouchard wrote:
On Tue, 11 Sep 2007, IOhannes m zmoelnig wrote:
- moved abstractions&extensions&xgui&Framestein into externals
good thing (snip) but I would rather have it under a common name that isn't "abstractions" nor "externals".
personally i think "externals" is exactly the name: it means "pd stuff that does not come with pd itself", rather than "pd-objects written in C"
i would narrow the definition to "pd-objects not internal to pd", but this is just an arbitrary decision of mine.
Yeah, sounds good to me.
.hc
mf.asdr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Hmmm I think the placement of trunk/tags/braches depends on what those things mean for PD...
Does it makes sense to have a branch of everything in CVS (as you suggest here) or a branch of just externals or PD (as frank's suggestion would do) or even to have a branch of a particular external then pd/externals/grill/branches.
I suppose you can copy a branch of just stable externals and put them in the root "branches" but my understanding of SVN was that these trunk/branches etc.. were per project... One trunk folder for everything does not make much sense to me...
.b.
IOhannes m zmoelnig wrote:
hi.
after the talk about svn at the pd-con, it seems like there is a general ok from the community, if somebody would be willing to perform the actual migration.
actually i could be this volunteer.
ad miller: there exist migration paths from both cvs and svn to git, so svn would do no harm before we can switch to git :-)
about the structure:
i have written down some ideas on how an svn-repository could be structured at http://puredata.info/Members/zmoelnig/pdcon07/SubVersion
basically the layout keeps the same, but with svn-specifics like meta-directories "trunk", "tags" and "branches". ideally (for me) the layout of "trunk" would be: /trunk/pd/ /trunk/pd-devel/ /trunk/desiredata/ /trunk/externals/ /trunk/packages/ /trunk/scripts/ /trunk/doc/
differences to the current layout are:
- moved abstractions&extensions&xgui&Framestein into externals
- desiredata&pd-devel live beside "pd" (not in a separate branch)
- htdocs is deprecated (but could as well move into "doc")
- "supercollider" has moved into scripts (i am not sure about this, but
it seems to be the best place, since "bash_completion" is already in there; "supercollider" is no external, it is rather a set of sc3-scripts to ease the use of pd&sc together)
the layout of "tags" would be: /tags/pd-0.40-4/ /tags/pd-0.41-1/ /tags/desiredata-0.39-1/ /tags/zexy-2.1/ /tags/pd-extended-0.39.2-rc1 ... (that is: a _very_ flat structure of "released" code)
the layout of "branches" would be almost the same as that of "tags" (but "tagged" revisions should not be touched any more, whereas "branched" revisions can be bug-fixed...)
both branches/tags should only be used for:
- releases (+maintenance)
- legacy (discontinued) projects
it is my believe that tags&branches should mainly be used for people who want to checkout "working code" (!), rather than developers who want to try something out without interfering with the existing code-base (trunk)
for quick experimental branches (e.g. if you want to implement a feature but do not want to spill the trunk), i would suggest a 4th meta-directory "experimental", like: /experimental/pd-0.40-kiosk/ /experimental/pd-extended-0.39-newbuildsystem/ projects in "experimental" are not meant to be continued, but their changes should go back into the main trunk (either by merging into the original project or by living besides it) in any case, these experimental branches should be deleted when finished, in order to keep the directory-layour reasonably small.
comments are highly welcome
fgmasd.r IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I use branches of the whole thing for Pd-extended, so I like this layout:
/branches/pd-extended/pd-extended-0-40-3
Also, the same goes for the trunk, I think we should think of all this stuff as one big project, or one meta-project if youwant to thikn about it that way. So I agree with IOhannes, having the subfolders in trunk rather than the trunk in the subfolder, i.e.
/trunk/pd/ /trunk/pd-devel/ /trunk/desiredata/ /trunk/externals/ /trunk/packages/ /trunk/scripts/ /trunk/doc/
About desiredata, as Matju stated, the plan is to not remain in synch with the code, but instead be compatible (sounds like a good idea, by the way). Therefore, it probably makes sense to have desiredata in it's own repository. But I suppose there is not harm done having a 'desiredata' trunk.
As for 'scripts', there needs to be a place for all the scripts needed to build Pd-extended. Whether that's also the place for bash_completion, etc, that's a separate question. What do other projects do for this stuff? This is not a unique question...
.hc
On Tue, 11 Sep 2007, B. Bogart wrote:
Hmmm I think the placement of trunk/tags/braches depends on what those things mean for PD...
Does it makes sense to have a branch of everything in CVS (as you suggest here) or a branch of just externals or PD (as frank's suggestion would do) or even to have a branch of a particular external then pd/externals/grill/branches.
I suppose you can copy a branch of just stable externals and put them in the root "branches" but my understanding of SVN was that these trunk/branches etc.. were per project... One trunk folder for everything does not make much sense to me...
.b.
IOhannes m zmoelnig wrote:
hi.
after the talk about svn at the pd-con, it seems like there is a general ok from the community, if somebody would be willing to perform the actual migration.
actually i could be this volunteer.
ad miller: there exist migration paths from both cvs and svn to git, so svn would do no harm before we can switch to git :-)
about the structure:
i have written down some ideas on how an svn-repository could be structured at http://puredata.info/Members/zmoelnig/pdcon07/SubVersion
basically the layout keeps the same, but with svn-specifics like meta-directories "trunk", "tags" and "branches". ideally (for me) the layout of "trunk" would be: /trunk/pd/ /trunk/pd-devel/ /trunk/desiredata/ /trunk/externals/ /trunk/packages/ /trunk/scripts/ /trunk/doc/
differences to the current layout are:
- moved abstractions&extensions&xgui&Framestein into externals
- desiredata&pd-devel live beside "pd" (not in a separate branch)
- htdocs is deprecated (but could as well move into "doc")
- "supercollider" has moved into scripts (i am not sure about this, but
it seems to be the best place, since "bash_completion" is already in there; "supercollider" is no external, it is rather a set of sc3-scripts to ease the use of pd&sc together)
the layout of "tags" would be: /tags/pd-0.40-4/ /tags/pd-0.41-1/ /tags/desiredata-0.39-1/ /tags/zexy-2.1/ /tags/pd-extended-0.39.2-rc1 ... (that is: a _very_ flat structure of "released" code)
the layout of "branches" would be almost the same as that of "tags" (but "tagged" revisions should not be touched any more, whereas "branched" revisions can be bug-fixed...)
both branches/tags should only be used for:
- releases (+maintenance)
- legacy (discontinued) projects
it is my believe that tags&branches should mainly be used for people who want to checkout "working code" (!), rather than developers who want to try something out without interfering with the existing code-base (trunk)
for quick experimental branches (e.g. if you want to implement a feature but do not want to spill the trunk), i would suggest a 4th meta-directory "experimental", like: /experimental/pd-0.40-kiosk/ /experimental/pd-extended-0.39-newbuildsystem/ projects in "experimental" are not meant to be continued, but their changes should go back into the main trunk (either by merging into the original project or by living besides it) in any case, these experimental branches should be deleted when finished, in order to keep the directory-layour reasonably small.
comments are highly welcome
fgmasd.r IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
zen \ \ \[D[D[D[D
Hans-Christoph Steiner wrote:
I use branches of the whole thing for Pd-extended, so I like this layout:
/branches/pd-extended/pd-extended-0-40-3
Also, the same goes for the trunk, I think we should think of all this stuff as one big project, or one meta-project if youwant to thikn about it that way. So I agree with IOhannes, having the subfolders in trunk rather than the trunk in the subfolder, i.e.
thanks :-) the main reason why i proposed the it like i did is: it changes the repositoy layout in a minimal way (compared to the current layout)
if you want to checkout the entire repository, you should be able to do something as simple as: svn co https://.../svnroot/pure-data/trunk and that's it. the other option would be: svn co https://.../svnroot/pure-data/pd/trunk pd svn co https://.../svnroot/pure-data/externals/zexy/trunk externs/zexy svn co https://.../svnroot/pure-data/externals/iem/trunk externs/iem ...
not really a one liner, isn't it?
otoh, one could create "bundles" in subversion that bundle together all the components you want. - either you could do this via links (that is "softlinks" as in unix filesystems), but i am not sure about this. - or, and that is one of the cool things in svn, by specifying "external" sources via the "svn:externals" property. this allows you to pull in a number of dependencies (repository directories) and rearrange them at your will.
but of course this is work to do for those who want to create a one-click checkout of the entire repository. (but then there are not so many people who really want that: obviously it would be good to be able to checkout the entire "trunk" of a working pd
honestly i think it is too much work to split the repository into sub-projects. (unless of course, there is a majority for organizing it like that)
mfg.asdr IOhannes
Hans-Christoph Steiner wrote:
About desiredata, as Matju stated, the plan is to not remain in synch with the code, but instead be compatible (sounds like a good idea, by the way). Therefore, it probably makes sense to have desiredata in it's own repository. But I suppose there is not harm done having a 'desiredata' trunk.
all the harm that is possible to do is done by this! what is the benefit if the code is maintained outside and there is an outdated revision in "trunk"?
i don't see a reason why desiredata should move out again into a separate repository, unless they wish to do so.
(and if you feel like you must import upstream code, it should be imported into a tag; it can then be referenced via the svn:externals; btw, svn:externals can also reference code outside _this_ repository (at least if it is in a subversion repository))
fmga.sdr IOhannes
On Wed, 12 Sep 2007, IOhannes m zmoelnig wrote:
i don't see a reason why desiredata should move out again into a separate repository, unless they wish to do so.
I don't see a reason either. I don't know why Hans is suggesting that. Perhaps it has to do with access control, but I don't remember how access control is in SVN, and I'm not going to look into it until I really have to.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Sep 13, 2007, at 4:49 PM, Mathieu Bouchard wrote:
On Wed, 12 Sep 2007, IOhannes m zmoelnig wrote:
i don't see a reason why desiredata should move out again into a separate repository, unless they wish to do so.
I don't see a reason either. I don't know why Hans is suggesting that. Perhaps it has to do with access control, but I don't remember how access control is in SVN, and I'm not going to look into it until I really have to.
You mentioned it in the past, Matju, so I thought I'd mention it now. I am not implying anything, it's just a suggestion.
.hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
------------------------------------------------------------------------ ----
Access to computers should be unlimited and total. - the hacker ethic
Hans-Christoph Steiner wrote:
As for 'scripts', there needs to be a place for all the scripts needed to build Pd-extended. Whether that's also the place for bash_completion, etc, that's a separate question.
but since it is the pd-repository rather than the pd-extended repository, it would probably be more appropriate to put all the scripts solely needed for pd-extended into "/misc/pd-extended/" rather than "/scripts/"
i think "bash_completion" is in there, because "scripts" are often associated with "sh" (and "bash"), and because of lack of a better section.
fmga.sdr IOhannes
On Sep 12, 2007, at 3:58 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
As for 'scripts', there needs to be a place for all the scripts needed to build Pd-extended. Whether that's also the place for bash_completion, etc, that's a separate question.
but since it is the pd-repository rather than the pd-extended repository, it would probably be more appropriate to put all the scripts solely needed for pd-extended into "/misc/pd-extended/" rather than "/scripts/"
i think "bash_completion" is in there, because "scripts" are often associated with "sh" (and "bash"), and because of lack of a better section.
fmga.sdr IOhannes
The 'scripts' section is not the pd-extended scripts section, for example:
scripts/debian/init.d/pd scripts/debian/default/pd scripts/generate-pd-settings-files.sh scripts/load_every_help.sh scripts/load_every_object.sh scripts/pd-diff scripts/auto-build/pd-devel-auto-builder.sh scripts/auto-build/pd-main-auto-builder.sh scripts/auto-build/pure-data-cvs-rsync scripts/auto-build/pure-data-cvs-rsync-checkout
etc. etc. "misc" is a meaningless term, I am not really a fan. 90% of the stuff in the 'scripts' section are indeed scripts...
.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
Hello,
I just missed the pdconv, so how is the authorization for the repository planed ? Is it possible to restrict access to a subfolder ?
If so I would recommend to put the trunk, tags, branches as subfolder of projects which can be deligated rather then have a very long list of versions for each external, subexternal or else in one directory. I would prefer:
pd/[trunk|branches|tags] pd-devel/[trunk|branches|tags] ... 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
since it is easy to filter out trunk in path for automatic builds, this should not be a problem and everybody has freedom to organize his projects with tags and branches and subfolder before tags and branches.
Please even its not possible today to give authorization to subfolder, it will be in near future and so the repository becomes readable finding tags and branches und we need not website for it to give short links.
mfg winfried
Also, the same goes for the trunk, I think we should think of all this stuff as one big project, or one meta-project if youwant to thikn about it that way. So I agree with IOhannes, having the subfolders in trunk rather than the trunk in the subfolder, i.e.
/trunk/pd/ /trunk/pd-devel/ /trunk/desiredata/ /trunk/externals/ /trunk/packages/ /trunk/scripts/ /trunk/doc/About desiredata, as Matju stated, the plan is to not remain in synch with the code, but instead be compatible (sounds like a good idea, by the way). Therefore, it probably makes sense to have desiredata in it's own repository. But I suppose there is not harm done having a 'desiredata' trunk.
As for 'scripts', there needs to be a place for all the scripts needed to build Pd-extended. Whether that's also the place for bash_completion, etc, that's a separate question. What do other projects do for this stuff? This is not a unique question...
.hc
On Tue, 11 Sep 2007, B. Bogart wrote:
Hmmm I think the placement of trunk/tags/braches depends on what those things mean for PD...
Does it makes sense to have a branch of everything in CVS (as you suggest here) or a branch of just externals or PD (as frank's suggestion would do) or even to have a branch of a particular external then pd/externals/grill/branches.
I suppose you can copy a branch of just stable externals and put them in the root "branches" but my understanding of SVN was that these trunk/branches etc.. were per project... One trunk folder for everything does not make much sense to me...
.b.
IOhannes m zmoelnig wrote:
hi.
after the talk about svn at the pd-con, it seems like there is a general ok from the community, if somebody would be willing to perform the actual migration.
actually i could be this volunteer.
ad miller: there exist migration paths from both cvs and svn to git, so svn would do no harm before we can switch to git :-)
about the structure:
i have written down some ideas on how an svn-repository could be structured at http://puredata.info/Members/zmoelnig/pdcon07/SubVersion
basically the layout keeps the same, but with svn-specifics like meta-directories "trunk", "tags" and "branches". ideally (for me) the layout of "trunk" would be: /trunk/pd/ /trunk/pd-devel/ /trunk/desiredata/ /trunk/externals/ /trunk/packages/ /trunk/scripts/ /trunk/doc/
differences to the current layout are:
- moved abstractions&extensions&xgui&Framestein into externals
- desiredata&pd-devel live beside "pd" (not in a separate branch)
- htdocs is deprecated (but could as well move into "doc")
- "supercollider" has moved into scripts (i am not sure about this, but
it seems to be the best place, since "bash_completion" is already in there; "supercollider" is no external, it is rather a set of sc3-scripts to ease the use of pd&sc together)
the layout of "tags" would be: /tags/pd-0.40-4/ /tags/pd-0.41-1/ /tags/desiredata-0.39-1/ /tags/zexy-2.1/ /tags/pd-extended-0.39.2-rc1 ... (that is: a _very_ flat structure of "released" code)
the layout of "branches" would be almost the same as that of "tags" (but "tagged" revisions should not be touched any more, whereas "branched" revisions can be bug-fixed...)
both branches/tags should only be used for:
- releases (+maintenance)
- legacy (discontinued) projects
it is my believe that tags&branches should mainly be used for people who want to checkout "working code" (!), rather than developers who want to try something out without interfering with the existing code-base (trunk)
for quick experimental branches (e.g. if you want to implement a feature but do not want to spill the trunk), i would suggest a 4th meta-directory "experimental", like: /experimental/pd-0.40-kiosk/ /experimental/pd-extended-0.39-newbuildsystem/ projects in "experimental" are not meant to be continued, but their changes should go back into the main trunk (either by merging into the original project or by living besides it) in any case, these experimental branches should be deleted when finished, in order to keep the directory-layour reasonably small.
comments are highly welcome
fgmasd.r IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
zen \ \ \[D[D[D[D
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Winfried Ritsch wrote:
Hello,
I just missed the pdconv, so how is the authorization for the repository planed ? Is it possible to restrict access to a subfolder ?
no, since the plan is to stay with sourceforge for now, there is still no way to restrict write access to submodules (afaik).
If so I would recommend to put the trunk, tags, branches as subfolder of projects which can be deligated rather then have a very long list of versions for each external, subexternal or else in one directory. I would prefer:
so how do you like thomas grill's suggestion to do it like /trunk/pd/ /trunk/externals/iem/comport /tags/pd/pd-<x>.<y> /branches/iem/comport-<x>.<y>
the problem with your suggestion i see is, that it is sometimes not really clear as to what is a "subproject" and what not. is it: /externals/iemlib/iemlib1/[trunk|branches|tags] or /externals/iemlib/[trunk|branches|tags]/iemlib1 ??
since it is easy to filter out trunk in path for automatic builds, this should not be a problem and everybody has freedom to organize his projects with tags and branches and subfolder before tags and branches.
well yes, as i have said before this is possible. but what is the benefit above doing it as one big project in the first place, if everybody who wants to checkout more than HEAD of pd-vanilla has to resort to setup some filtering (or use meta-projects like svn:externals)
and finally: cvs2svn automatically creates one big project, so everything else would be extra work :-)
fmasdr IOhannes
hello,
I just missed the pdconv, so how is the authorization for the repository planed ? Is it possible to restrict access to a subfolder ?
no, since the plan is to stay with sourceforge for now, there is still no way to restrict write access to submodules (afaik).
If so I would recommend to put the trunk, tags, branches as subfolder of projects which can be deligated rather then have a very long list of versions for each external, subexternal or else in one directory. I would prefer:
so how do you like thomas grill's suggestion to do it like /trunk/pd/ /trunk/externals/iem/comport /tags/pd/pd-<x>.<y> /branches/iem/comport-<x>.<y>
its quite the same as a general trunk,branches, tags structure.
the problem with your suggestion i see is, that it is sometimes not really clear as to what is a "subproject" and what not. is it: /externals/iemlib/iemlib1/[trunk|branches|tags] or /externals/iemlib/[trunk|branches|tags]/iemlib1 ??
but this a benefit, since with this organisation everybody know which is a subproject, since developerstructure is unclear now and dependencies of libraries are encapsulated like miXed.
since it is easy to filter out trunk in path for automatic builds, this should not be a problem and everybody has freedom to organize his projects with tags and branches and subfolder before tags and branches.
well yes, as i have said before this is possible. but what is the benefit above doing it as one big project in the first place, if everybody who wants to checkout more than HEAD of pd-vanilla has to resort to setup some filtering (or use meta-projects like svn:externals)
the benefit is that its clear what is a subproject and that developer can organize their project like they want or also in respect of their internal organization, also another benefit is that with meta-project its easy to make bundles for automatic build systems add and remove projects without touch them.
and finally: cvs2svn automatically creates one big project, so everything else would be extra work :-)
thats true, but much work now is less work in the future, since the delegation is much more clear:
- Also in future when there will be (and i think it will be not to far) a possibility for individual access on folders, delegation doesnt need restructuring the repository for tags and branches.
- its easier to give access doing branches or tags for everybody in his project (release early and release often ;-).
- if a project is removed because of any reasons (legal, personal) you dont need to find all branches and tags and experimental entries, since you never know how they are named).
Its also easier to link the projects to the softwarecenter in puredata.info, as you did with Gem. "One svn place for one project." (http://puredata.info/community/projects/software)
and I saw this structure in other community projects (like plone, etc...) which seems to work.
This could be the steps for finalizing the structure (so not much more work has to be done as the other solution):
1) just do cvs2svn
2) do a branching tagging on basefolder like pd, pd-extented, ... not external with svn mv, svn cp
3) tell the poeple accessing their project they should do so if they want. Maybe some primitive external libraries, dont need it since revision numbering is enough or already finished, so just leave them without trunk, branches whatever...
mfg winfried
-
B. Bogart -
Chris McCormick -
David Plans Casal -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Luke Iannini (pd) -
Mathieu Bouchard -
Steffen -
Thomas Grill -
Winfried Ritsch