Dear pd-dev,
Should DesireData remain part of the "pure-data" sf-project, or become a separate sf-project just like GEM already is?...
I ask because HCS seems quite concerned by the thought that DesireData might stay in the repository. He seems to claim that moving DesireData out of the repository, would be a way of collaborating with him.
What do you think?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hallo, I'd personally greatly appreciate it if DD was kept in the pure-data project. For my own eventual contribution to DD, it would be far more convenient.
There's nothing in the SVN ethos that precludes multiple projects in one repository; I believe it's in fact the recommended configuration. It's simply a matter of organization.
As much as I support the use of SVN:externals as a handy tool, if given the choice it's optimal to just have everything in the same repository. I have a web startup which most definitely has many projects running concurrently in the same repository, as well as externals definitions for tracking other projects (and internal folders too), so I am speaking from experience in saying this.
Also, no one has to check out everything; often users will just check out a certain subdirectory of the repository that they're interested in.
Cheers Luke
On Feb 6, 2008 6:08 PM, Mathieu Bouchard matju@artengine.ca wrote:
Dear pd-dev,
Should DesireData remain part of the "pure-data" sf-project, or become a separate sf-project just like GEM already is?...
I ask because HCS seems quite concerned by the thought that DesireData might stay in the repository. He seems to claim that moving DesireData out of the repository, would be a way of collaborating with him.
What do you think?
_ _ __ ___ _____ ________ _____________ _____________________ ... | 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
Since DD is a fork, I think it should not be a branch of Pd in the repository. It can be in the same repository, I don't care either way about that. I think IOhannes proposed something like this (but maybe something else makes more sense?):
abstractions doc pd externals desiredata
I expected they would have wanted their own repository so that they can control it themselves without having to deal with the Pd overhead (adding devs, commit policy, etc). But I guess not.
.hc
On Feb 6, 2008, at 9:08 PM, Mathieu Bouchard wrote:
Dear pd-dev,
Should DesireData remain part of the "pure-data" sf-project, or become a separate sf-project just like GEM already is?...
I ask because HCS seems quite concerned by the thought that DesireData might stay in the repository. He seems to claim that moving DesireData out of the repository, would be a way of collaborating with him.
What do you think?
_ _ __ ___ _____ ________ _____________ _____________________ ... | 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
------------------------------------------------------------------------ ----
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
On Thu, 7 Feb 2008, Hans-Christoph Steiner wrote:
Since DD is a fork, I think it should not be a branch of Pd in the repository. It can be in the same repository, I don't care either way about that.
Why are you becoming suddenly unconcerned with the commit-history and pd-cvs mailing-list? This is not what you have told me last week.
There's not much of a difference between a branch and a non-branch in SVN, so I don't mind so much about that, as long as SVN really handles the renaming perfectly.
I expected they would have wanted their own repository so that they can control it themselves without having to deal with the Pd overhead (adding devs, commit policy, etc). But I guess not.
adding devs could be a reason in the future, if we have more people who _regularly_ need to commit, but aren't accepted as devs in the pure-data sf-project. For once-a-month would-be-committers, I don't mind doing it for them, frankly.
I don't know what you mean about the "commit policy". What is that?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Feb 7, 2008, at 3:38 PM, Mathieu Bouchard wrote:
On Thu, 7 Feb 2008, Hans-Christoph Steiner wrote:
Since DD is a fork, I think it should not be a branch of Pd in the repository. It can be in the same repository, I don't care either way about that.
Why are you becoming suddenly unconcerned with the commit-history and pd-cvs mailing-list? This is not what you have told me last week.
When looking at a file, say pd/src/s_file.c, then there are be dd- specific commits in the history, that's what I mean. As for the pd- cvs mailing list, I can live with seeing the dd commit messages there. ;)
There's not much of a difference between a branch and a non-branch in SVN, so I don't mind so much about that, as long as SVN really handles the renaming perfectly.
I expected they would have wanted their own repository so that they can control it themselves without having to deal with the Pd overhead (adding devs, commit policy, etc). But I guess not.
adding devs could be a reason in the future, if we have more people who _regularly_ need to commit, but aren't accepted as devs in the pure-data sf-project. For once-a-month would-be-committers, I don't mind doing it for them, frankly.
I don't know what you mean about the "commit policy". What is that?
Many repositories have scripted commit policies that check all sorts of things before allowing a commit, things like it needs to compile, it needs not use deprecate libraries, etc. etc.
.hc
------------------------------------------------------------------------ ----
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
On Feb 7, 2008 12:47 PM, Hans-Christoph Steiner hans@eds.org wrote:
When looking at a file, say pd/src/s_file.c, then there are be dd- specific commits in the history, that's what I mean. As for the pd- cvs mailing list, I can live with seeing the dd commit messages there. ;)
Hi Hans, If DD is actually branched, then one would only see those commits in the log of that branch (aka directory). /desiredata/pd becomes basically independent. The only shared thing would be the log up to the point of the branch, plus whatever merging one decides to do from elsewhere (which sounds greatly improved in svn 1.5, by the way).
Cheers Luke
On Feb 7, 2008, at 4:06 PM, Luke Iannini (pd) wrote:
On Feb 7, 2008 12:47 PM, Hans-Christoph Steiner hans@eds.org wrote:
When looking at a file, say pd/src/s_file.c, then there are be dd- specific commits in the history, that's what I mean. As for the pd- cvs mailing list, I can live with seeing the dd commit messages there. ;)
Hi Hans, If DD is actually branched, then one would only see those commits in the log of that branch (aka directory). /desiredata/pd becomes basically independent. The only shared thing would be the log up to the point of the branch, plus whatever merging one decides to do from elsewhere (which sounds greatly improved in svn 1.5, by the way).
This is an example of what I mean, the default browse views for the logs show all of the branches. I'll be svn works similarly
http://pure-data.cvs.sourceforge.net/pure-data/pd/src/s_stuff.h
branches are a tool generally used for code that is intended to be included in the code that it is branched from. When a codebase becomes a fork, then there is no longer that intension. Matju has submitted few if any patches to the tracker and has publically declared dd is a fork. So I am just suggesting that we use the tools well, which will also hopefully help some social issues.
This is not a question of whether I think DD is worthwhile or not, I have contributed work towards supporting DD and I think it is worthwhile. This is just a question of using the tools well.
.hc
------------------------------------------------------------------------ ----
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
Hans-Christoph Steiner wrote:
On Feb 7, 2008, at 4:06 PM, Luke Iannini (pd) wrote:
On Feb 7, 2008 12:47 PM, Hans-Christoph Steiner hans@eds.org wrote:
When looking at a file, say pd/src/s_file.c, then there are be dd- specific commits in the history, that's what I mean. As for the pd- cvs mailing list, I can live with seeing the dd commit messages there. ;)
Hi Hans, If DD is actually branched, then one would only see those commits in the log of that branch (aka directory). /desiredata/pd becomes basically independent. The only shared thing would be the log up to the point of the branch, plus whatever merging one decides to do from elsewhere (which sounds greatly improved in svn 1.5, by the way).
This is an example of what I mean, the default browse views for the logs show all of the branches. I'll be svn works similarly
http://pure-data.cvs.sourceforge.net/pure-data/pd/src/s_stuff.h
no need to bet.
just have a look at http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/pd/src/s_stuff.h and see that your fears are without cause.
mfg.adr IOhannes
On Feb 7, 2008 12:47 PM, Hans-Christoph Steiner hans@eds.org wrote:
Many repositories have scripted commit policies that check all sorts of things before allowing a commit, things like it needs to compile, it needs not use deprecate libraries, etc. etc.
These can also be easily implemented if desired on a per-directory basis. http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.ref.reposhooks
Cheers Luke
Luke Iannini (pd) wrote:
On Feb 7, 2008 12:47 PM, Hans-Christoph Steiner hans@eds.org wrote:
Many repositories have scripted commit policies that check all sorts of things before allowing a commit, things like it needs to compile, it needs not use deprecate libraries, etc. etc.
These can also be easily implemented if desired on a per-directory basis. http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.ref.reposhooks
well, yes; but not on sourceforge. sf offers a small number of hooks you can choose (e.g. commitmails, filename-checks) but only for the entire repository.
now that i think of it, i wonder why sf has not implemented ACLs via a precommit hook...
gfmadr. IOhannes
On Thu, 7 Feb 2008, Hans-Christoph Steiner wrote:
When looking at a file, say pd/src/s_file.c, then there are be dd-specific commits in the history, that's what I mean.
That's been mostly over for a while. Most changes in DesireData in the past year were in merged files with a new name... for example, m_*.c became a new file named kernel.c. Most d_*.c are now builtins_dsp.c, most x_*.c are now builtins.c, etc. Just like desire.c was g_*.c since mid-2005. Some files are still not renamed nor merged, mostly s_*.c.
Many repositories have scripted commit policies that check all sorts of things before allowing a commit, things like it needs to compile, it needs not use deprecate libraries, etc. etc.
Well, neither the PureData nor the DesireData projects have that, and I don't think I've ever heard such scripts being discussed on the pd-dev mailing-list. So, why would it be an issue now?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Feb 7, 2008, at 4:20 PM, Mathieu Bouchard wrote:
On Thu, 7 Feb 2008, Hans-Christoph Steiner wrote:
When looking at a file, say pd/src/s_file.c, then there are be dd- specific commits in the history, that's what I mean.
That's been mostly over for a while. Most changes in DesireData in the past year were in merged files with a new name... for example, m_*.c became a new file named kernel.c. Most d_*.c are now builtins_dsp.c, most x_*.c are now builtins.c, etc. Just like desire.c was g_*.c since mid-2005. Some files are still not renamed nor merged, mostly s_*.c.
This is a good example of why dd shouldn't be a branch of pd. If you are introducing new files that are never intended to be included in pd/src, then it just gets messy having those extra non-pd files in the repository while providing no benefit that I can think of.
Many repositories have scripted commit policies that check all sorts of things before allowing a commit, things like it needs to compile, it needs not use deprecate libraries, etc. etc.
Well, neither the PureData nor the DesireData projects have that, and I don't think I've ever heard such scripts being discussed on the pd-dev mailing-list. So, why would it be an issue now?
It has been discussed in the past. But I was saying more that you would be free to implement your own such policies if you used your own repository.
I really don't see any real advantage to keeping dd in the pure-data repository.
.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
Hans-Christoph Steiner wrote:
On Feb 7, 2008, at 4:20 PM, Mathieu Bouchard wrote:
On Thu, 7 Feb 2008, Hans-Christoph Steiner wrote:
When looking at a file, say pd/src/s_file.c, then there are be dd- specific commits in the history, that's what I mean.
That's been mostly over for a while. Most changes in DesireData in the past year were in merged files with a new name... for example, m_*.c became a new file named kernel.c. Most d_*.c are now builtins_dsp.c, most x_*.c are now builtins.c, etc. Just like desire.c was g_*.c since mid-2005. Some files are still not renamed nor merged, mostly s_*.c.
This is a good example of why dd shouldn't be a branch of pd. If you are introducing new files that are never intended to be included in pd/src, then it just gets messy having those extra non-pd files in the repository while providing no benefit that I can think of.
there are no branches in subversion. there are directories. there is no difference in the logfiles, whether dd is /desiredata/pd or /trunk/desiredata or whatever. logs do not interfere. they are bound to an object and not to a file. 2 objects can share part of the log, when object-2 was _copied_ ("svn copy") from object-1; they will only share the log to the point when there ways departed.
mfgasdr-. IOhannes
On Feb 7, 2008 1:35 PM, Hans-Christoph Steiner hans@eds.org wrote:
On Feb 7, 2008, at 4:20 PM, Mathieu Bouchard wrote:
On Thu, 7 Feb 2008, Hans-Christoph Steiner wrote:
When looking at a file, say pd/src/s_file.c, then there are be dd- specific commits in the history, that's what I mean.
That's been mostly over for a while. Most changes in DesireData in the past year were in merged files with a new name... for example, m_*.c became a new file named kernel.c. Most d_*.c are now builtins_dsp.c, most x_*.c are now builtins.c, etc. Just like desire.c was g_*.c since mid-2005. Some files are still not renamed nor merged, mostly s_*.c.
This is a good example of why dd shouldn't be a branch of pd. If you are introducing new files that are never intended to be included in pd/src, then it just gets messy having those extra non-pd files in the repository while providing no benefit that I can think of.
Now I'm very confused; perhaps it is because I have never used CVS. How are these files any different from the many "non-pd" files you'll find in the hundreds of directories in "externals"? It seems your concern is that DD is going to somehow "pollute" the purity of the trunk, but I'm assuring you that in SVN this is not the case in any way. "Branches" (which, like everything, are just directories) are entirely independent entities. You'll no more see DD files or logs or anything from /desiredata/pd/src in /trunk/pd/src than you will see, say /trunk/externals/zexy files in /trunk/pd/src
just a side-note:
Luke Iannini (pd) wrote:
entirely independent entities. You'll no more see DD files or logs or anything from /desiredata/pd/src in /trunk/pd/src than you will see,
"desiredata" is an equivalent of "pd", so in my nice little world, it would be /trunk/pd/src and /trunk/desiredata/src rather than /desiredata/pd/src (there is really no reason to have a "pd" subfolder in "desiredata")
but this is just nitpicking.
fgmasdr IOhannes
On 7 Feb 2008, at 21:56, IOhannes m zmoelnig wrote:
"desiredata" is an equivalent of "pd", so in my nice little world, it would be /trunk/pd/src and /trunk/desiredata/src rather than /desiredata/pd/src (there is really no reason to have a "pd" subfolder in "desiredata")
but this is just nitpicking.
It is, however, correct...
David
On Thu, 7 Feb 2008, IOhannes m zmoelnig wrote:
"desiredata" is an equivalent of "pd", so in my nice little world, it would be /trunk/pd/src and /trunk/desiredata/src rather than /desiredata/pd/src (there is really no reason to have a "pd" subfolder in "desiredata") but this is just nitpicking.
Depends... I have another question... what if I want to fork/branch (whatever one calls it) other folders outside of the /trunk/pd hierarchy? CVS makes it easy to branch individual files, or specific subfolders without necessarily branching everything containing it. How is that supported by SVN ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On 12 Feb 2008, at 20:31, Mathieu Bouchard wrote:
On Thu, 7 Feb 2008, IOhannes m zmoelnig wrote:
"desiredata" is an equivalent of "pd", so in my nice little world, it would be /trunk/pd/src and /trunk/desiredata/src rather than / desiredata/pd/src (there is really no reason to have a "pd" subfolder in "desiredata") but this is just nitpicking.
Depends... I have another question... what if I want to fork/branch (whatever one calls it) other folders outside of the /trunk/pd hierarchy? CVS makes it easy to branch individual files, or specific subfolders without necessarily branching everything containing it.
Branches can be wildly different than the trunk, but a fork is fork, surely.
How is that supported by SVN ?
Tags, AFAIK.
David
On Tue, 12 Feb 2008, David Plans Casal wrote:
On 12 Feb 2008, at 20:31, Mathieu Bouchard wrote:
Depends... I have another question... what if I want to fork/branch (whatever one calls it) other folders outside of the /trunk/pd hierarchy? CVS makes it easy to branch individual files, or specific subfolders without necessarily branching everything containing it.
Branches can be wildly different than the trunk, but a fork is fork, surely.
So, how does that change how the SVN is to be managed? What are you trying to say?
How is that supported by SVN ?
Tags, AFAIK.
So, if tags can fulfill the same purpose as branches do, why do we have branches as plain folders? I don't think that this is the answer.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On 13 Feb 2008, at 00:24, Mathieu Bouchard wrote:
On Tue, 12 Feb 2008, David Plans Casal wrote:
On 12 Feb 2008, at 20:31, Mathieu Bouchard wrote:
Depends... I have another question... what if I want to fork/branch (whatever one calls it) other folders outside of the /trunk/pd hierarchy? CVS makes it easy to branch individual files, or specific subfolders without necessarily branching everything containing it.
Branches can be wildly different than the trunk, but a fork is fork, surely.
So, how does that change how the SVN is to be managed? What are you trying to say?
I was just saying that desiredata changes fundamental parts of the pd infrastructure as far as I can tell, and so as hans pointed out, possibly does not belong where it is now in svn.
How is that supported by SVN ?
Tags, AFAIK.
So, if tags can fulfill the same purpose as branches do, why do we have branches as plain folders? I don't think that this is the answer.
I think you might benefit from reading the redbean book:
And look at the difference between tags and branches. Everything in svn -is- a folder in any case.
David
On Wed, 13 Feb 2008, David Plans Casal wrote:
I was just saying that desiredata changes fundamental parts of the pd infrastructure as far as I can tell, and so as hans pointed out, possibly does not belong where it is now in svn.
Where do you think it is now in svn? (btw, _I_ didn't move it)
How is that supported by SVN ?
Tags, AFAIK.
So, if tags can fulfill the same purpose as branches do, why do we have branches as plain folders? I don't think that this is the answer.
look at the difference between tags and branches. Everything in svn -is- a folder in any case.
Ok. Then tags have nothing to do with what I want.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Mathieu Bouchard wrote:
On Thu, 7 Feb 2008, IOhannes m zmoelnig wrote:
"desiredata" is an equivalent of "pd", so in my nice little world, it would be /trunk/pd/src and /trunk/desiredata/src rather than /desiredata/pd/src (there is really no reason to have a "pd" subfolder in "desiredata") but this is just nitpicking.
Depends... I have another question... what if I want to fork/branch (whatever one calls it) other folders outside of the /trunk/pd hierarchy? CVS makes it easy to branch individual files, or specific
why would you want to do so? the only reason i see is, that you are already used to this practice.
svn has the concept of _larger_ atomic commits (very unlike cvs) - this is based on the assumption, that a change (or file,...) must always be seen in a larger context. example: if i have a function defined in fileA and used in fileB; if i rename the function in fileA, i have to change fileB inoder to stay consistent; so the 2 changes are interdependent; in svn i can commit the changes to both files in a single atomic transaction to ensure consistency of the repository; CVS does not provide such a mechanism (e.g. if i managed to commit my change to fileA but _not_ to fileB because of a conflict, the entire repository will be in an inconsistent state) why am i telling you this? because single files usually do not make sense without their context (neighbouring files) - it therefore is useless to tag a single file. if you are absolutely sure that you have to do so, you can - of course - just "svn copy" your file to a new position - and branched it is.
fgmasdr, IOhannes
On Wed, 13 Feb 2008, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
Depends... I have another question... what if I want to fork/branch (whatever one calls it) other folders outside of the /trunk/pd hierarchy? CVS makes it easy to branch individual files, or specific
why would you want to do so?
I was thinking about e.g. if I want to add some files to documentation, but want updates of documentation of the trunk to automatically make my branch updated.
the only reason i see is, that you are already used to this practice.
Ok, if this is the only reason, and I am already used to this practice, how would I get into this practice in the first place?
svn has the concept of _larger_ atomic commits (very unlike cvs) - this is based on the assumption, that a change (or file,...) must always be seen in a larger context.
Well, I was also thinking about whether it'd be a good idea to make changes to makefiles of /trunk/externals but only in my branch. In the end I think that it wouldn't be so good an idea, exactly because the Makefile only makes sense in a larger context... updates to the trunk would eventually cause trouble to the branch.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Feb 13, 2008 10:57 AM, Mathieu Bouchard matju@artengine.ca wrote:
On Wed, 13 Feb 2008, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
Depends... I have another question... what if I want to fork/branch (whatever one calls it) other folders outside of the /trunk/pd hierarchy? CVS makes it easy to branch individual files, or specific
why would you want to do so?
I was thinking about e.g. if I want to add some files to documentation, but want updates of documentation of the trunk to automatically make my branch updated.
Maybe not /quite/ what you're looking for, but you can do this in desiredata/doc: svn propedit svn:externals .
It will pop you into an editor (well, you have to set it in ~/.subversion/config first), where you can add: 1.manual https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/pd/1.manual 2.control.examples https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/pd/2.control.e... 3.audio.examples https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/pd/3.audio.exa... 4.data.structures https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/pd/4.data.stru... 5.reference https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/pd/5.reference 6.externs https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/pd/6.externs 7.stuff https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/pd/7.stuff sound https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/pd/sound
and then you'd need another folder for dd stuff (or of course you could create dddoc/ one level up and just track doc/).
Those folders would update every time you ran "svn up" in a dir above them, and changes you make to them locally will not be committed unless you explicitly "svn ci" from inside one of those folders.
svn:externals modifications get checked in to the repository like anything else, so this change would propagate to everyone with desiredata/ checked out.
Cheers Luke
Mathieu Bouchard wrote:
Dear pd-dev,
Should DesireData remain part of the "pure-data" sf-project, or become a separate sf-project just like GEM already is?...
i think this is entirely within the responibility of the DesireData developers.
I ask because HCS seems quite concerned by the thought that DesireData might stay in the repository. He seems to claim that moving DesireData out of the repository, would be a way of collaborating with him.
What do you think?
i do not see a reason for you to move out of the pure-data repository, if you are happy there. if you are not, it might be worth considering.
the current repository is neither the dd repository, nor the pd-extended repository. it is the pure-data repository. both projects could technically be moved out and still retain the same functionality (development wise).
i prefer to ignore (but like always, fail to do so) the attacks between you and hans; the only thing they tell me, is that both of you should either have a good look at the repository's features to see whether there is really a problem, or go to the blutwiesn.
mfgasd.r IOhannes
On Feb 7, 2008, at 5:13 PM, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
Dear pd-dev,
Should DesireData remain part of the "pure-data" sf-project, or become a separate sf-project just like GEM already is?...
i think this is entirely within the responibility of the DesireData developers.
I ask because HCS seems quite concerned by the thought that DesireData might stay in the repository. He seems to claim that moving DesireData out of the repository, would be a way of collaborating with him.
What do you think?
i do not see a reason for you to move out of the pure-data repository, if you are happy there. if you are not, it might be worth considering.
the current repository is neither the dd repository, nor the pd- extended repository. it is the pure-data repository. both projects could technically be moved out and still retain the same functionality (development wise).
i prefer to ignore (but like always, fail to do so) the attacks between you and hans; the only thing they tell me, is that both of you should either have a good look at the repository's features to see whether there is really a problem, or go to the blutwiesn.
Pd-extended would be much more work to maintain outside of the pure- data repository. It is a distro of pd, it is not something different. I don't think that a distro should be thought of something separate. The reason why Pd-extended uses branches is for making releases, just like asterisk or subversion itself.
As for the log issue with dd, it seems that svn has made dd separate... and just to be clear, I started this discussion to make more effective use of the tools (CVS). I often had to wade thru lots of dd log messages. Since dd is a fork, I thought it made sense to have separate logs. It seems svn has done that for us. :)
.hc
mfgasd.r IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
On Thu, 7 Feb 2008, IOhannes m zmoelnig wrote:
Should DesireData remain part of the "pure-data" sf-project, or become a separate sf-project just like GEM already is?...
i think this is entirely within the responibility of the DesireData developers.
I'm not talking about whose responsibility it is to decide that, I'm talking about what's convenient for whom, and what's a concern for whom.
blutwiesn.
Can't find this in a dictionary...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
http://www.ostarrichi.org/wort-6334-at-Bluatwiesn+(Blutwiese).html usually found in "Sich auf der Bluatwiesn treffen" which means to fight something out on the field. you say this as a threat, but never do it (only kindergarten). marius.
Mathieu Bouchard wrote:
On Thu, 7 Feb 2008, IOhannes m zmoelnig wrote:
Should DesireData remain part of the "pure-data" sf-project, or become a separate sf-project just like GEM already is?...
i think this is entirely within the responibility of the DesireData developers.
I'm not talking about whose responsibility it is to decide that, I'm talking about what's convenient for whom, and what's a concern for whom.
blutwiesn.
Can't find this in a dictionary...
_ _ __ ___ _____ ________ _____________ _____________________ ... | 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
-
David Plans Casal -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Luke Iannini (pd) -
marius schebella -
Mathieu Bouchard