hi,
i've got this dilemna right now :
i agree for distributing my externals with Demudi but i'd rather not store them in the CVS repository.. why? hum, i don't want to support objects which have been modified without a prior agreement and a code review, leaving them in CVS is letting the things go that way...
i'd rather not.
cheers,
sevy/yves
Hi Yves,
i don't want to support objects which have been modified without a prior agreement and a code review, leaving them in CVS is letting the things go that way...
the same applies to my code, but i'm sure that the cvs-participants do not alter the code of another author without notice. I'd like to support the cvs for convenience reasons. Packing a release (for 3 or more platforms in my case) is a few hours' work every time. I hope that i can avoid all the minor releases and bugfixes that way.
best greetings, Thomas
On Tue, 19 Nov 2002, Thomas Grill wrote:
Hi Yves, the same applies to my code, but i'm sure that the cvs-participants do not alter the code of another author without notice. I'd like to support the cvs for convenience reasons. Packing a release (for 3 or more platforms in my case) is a few hours' work every time. I hope that i can avoid all the minor releases and bugfixes that way.
I know I was flogging this earlier on the pd-dev list, but Yves and Thomas seem to share my concerns about free write access. It is possible to set up commit permissions, then people don't have to give up any control over their code to put it up on pure-data.sf.net and the community gets the benefit of a centralized repository.
Here's what Sourceforge has to say about permissions:
-- How can I place restrictions on developer write access to my repository?
While SourceForge.net does not currently provide the means to restrict
developer write access to a project CVS repository, you may make use of the cvs_acls script, provided in the CVS software distribution. The cvs_acls script is used in conjunction with the commitinfo file in the CVSROOT module for your project, as to limit developer access to specific portions of the repository. --
CVS provides 'commitinfo' for this very purpose, combined with this perl script 'cvs_acls' (http://collaboratory.psc.edu/tools/cvs/faq.html) Plus 'commitinfo' can also be used for running pre-checkin test routines. Here's what the docs have to say: http://www.cvshome.org/docs/manual/cvs_18.html#SEC167
I'll take a shot at setting this up if someone is interested.
.hc
zen
\
\
\[D[D[D[D
On Mon, 18 Nov 2002, Hans-Christoph Steiner wrote:
Here's what Sourceforge has to say about permissions:
-- How can I place restrictions on developer write access to my repository?
While SourceForge.net does not currently provide the means to restrict
developer write access to a project CVS repository, you may make use of the cvs_acls script, provided in the CVS software distribution. The cvs_acls script is used in conjunction with the commitinfo file in the CVSROOT module for your project, as to limit developer access to specific portions of the repository. --
CVS provides 'commitinfo' for this very purpose, combined with this perl script 'cvs_acls' (http://collaboratory.psc.edu/tools/cvs/faq.html) Plus 'commitinfo' can also be used for running pre-checkin test routines. Here's what the docs have to say: http://www.cvshome.org/docs/manual/cvs_18.html#SEC167
I'll take a shot at setting this up if someone is interested.
Yes, if someone wants this you just have to set it up. I am not at all against it, I just did not do it because it is not relevant for me personally.
Then, I think that yves externals are much to important to be not included in demudi, so I would put them anyway.
The thing is that I would put them into the CVS as they are, and if there are new versions I will have to update the CVS. And sometimes, for new releases I might forget to track down the latest versions.
But, I already consider the external CVS as a success, and it makes life a lot easier for me already, hopefully, in the near future it will make the live easier for all pd users too.
Guenter
Hi, guenter geiger hat gesagt: // guenter geiger wrote:
CVS provides 'commitinfo' for this very purpose, combined with this perl script 'cvs_acls' (http://collaboratory.psc.edu/tools/cvs/faq.html) Plus 'commitinfo' can also be used for running pre-checkin test routines. Here's what the docs have to say: http://www.cvshome.org/docs/manual/cvs_18.html#SEC167
I'll take a shot at setting this up if someone is interested.
Yes, if someone wants this you just have to set it up. I am not at all against it, I just did not do it because it is not relevant for me personally.
I think, in general this is a good idea. Developers like Yves and Thomas, who are concerned, that their code might be changed without their approval, need to have a way to make sure, that this doesn't happen.
Personally I welcome bugfixes for my externals (and makefiles :), so I don't care, if I'm the only one or not with write permissions to ext./footils/. I trust you guys :) ... but it's not only a matter of trust, it also is a matter of security.
I also think, that the Pd main directory "pure-data" should have a stricter checking of permissions. I would appreciate it, if Miller would use sourceforge for his releases as well, but I understand, that he as the main developer needs to have a branch/directory, where only he and maybe a handful of intimates can commit.
But, I already consider the external CVS as a success, and it makes life a lot easier for me already, hopefully, in the near future it will make the live easier for all pd users too.
I has made life easier for me, too, and I really think, that the CVS is one of the great things, that have happend to the Pd community recently (the other is "undo"). Having all externals alway at one's "cvs update"-fingertips is so much more comfortable than surfing the web for externals...
Frank Barknecht _ ______footils.org__
hi,
Then, I think that yves externals are much to important to be not included in demudi, so I would put them anyway.
))) thank you sooo much, but can this be done without putting them in CVS ?
the problem is not only unauthorized modifications ( of unauthorized pd ) but all the amount of work to set up acls and putting the objects in CVS.
i don't even know where to start.
cheers,
sevy/yves
Hi, Yves Degoyon hat gesagt: // Yves Degoyon wrote:
))) thank you sooo much, but can this be done without putting them in CVS ?
the problem is not only unauthorized modifications ( of unauthorized pd ) but all the amount of work to set up acls and putting the objects in CVS.
i don't even know where to start.
You're on linux, right? Then you probably already have all needed software (on your distro's CDs)
Guenther has written a great introduction for Pd developers, who want to use the CVS. It's on the front page of pure-data.sf.net
Basically you start with creating an account at sourceforge. Just go to any SF page (e.g. http://sourceforge.net/projects/pure-data), try to visit "my sf.net" and create a new account or go directly to http://sourceforge.net/account/register.php
After this procedure, you tell Guenther your SF name, and he will add you to the members list for pure-data.
After that, you can follow the instructions from pure-data.sf.net to using pd-CVS.
And after that, working is much easier that before, IMO.
You keep a source tree at home, and when you are done editing, you just type "cvs commit" to put your changed code to sf.net
If you messed up your code, you can just "cvs update" to come back to a previous version, that's still on CVS. Even versions of previous files are available there. Using CVS is too nice to be missed.
Frank Barknecht _ ______footils.org__
hum, i've been using CVS for years, that's not the point.
the point was : how to get registered on pure data's CVS ?? and is it worth doing it ?
anyway, i don't have the time and don't want to do it.
bye,
sevy/yves
Frank Barknecht wrote:
Hi, Yves Degoyon hat gesagt: // Yves Degoyon wrote:
))) thank you sooo much, but can this be done without putting them in CVS ?
the problem is not only unauthorized modifications ( of unauthorized pd ) but all the amount of work to set up acls and putting the objects in CVS.
i don't even know where to start.
You're on linux, right? Then you probably already have all needed software (on your distro's CDs)
Guenther has written a great introduction for Pd developers, who want to use the CVS. It's on the front page of pure-data.sf.net
Basically you start with creating an account at sourceforge. Just go to any SF page (e.g. http://sourceforge.net/projects/pure-data), try to visit "my sf.net" and create a new account or go directly to http://sourceforge.net/account/register.php
After this procedure, you tell Guenther your SF name, and he will add you to the members list for pure-data.
After that, you can follow the instructions from pure-data.sf.net to using pd-CVS.
And after that, working is much easier that before, IMO.
You keep a source tree at home, and when you are done editing, you just type "cvs commit" to put your changed code to sf.net
If you messed up your code, you can just "cvs update" to come back to a previous version, that's still on CVS. Even versions of previous files are available there. Using CVS is too nice to be missed.
ciao
!sevy ih
hum, i've been using CVS for years, that's not the point.
the point was : how to get registered on pure data's CVS ?? and is it worth doing it ?
it's not that hard. a simple registering, at http://sourceforge.net/account/register.php and you are member of sf.net you don't even need the maiden name of your cat ;-) regards d13b
Hi, Yves Degoyon hat gesagt: // Yves Degoyon wrote:
hum, i've been using CVS for years, that's not the point.
Ahm, sorry, I didn't want to step on your toes, if I did. This wasn't clear to me.
the point was : how to get registered on pure data's CVS ?? and is it worth doing it ?
It is very easy, and you get just another email adress, as well.
anyway, i don't have the time and don't want to do it.
If you don't want to, it's end of story, but it's really easy and quick to register... ;)
Now I'll shut up.
Frank Barknecht _ ______footils.org__
One thing that may help against the fear of 'wild' codechanges is setting up a mailinglist (eg. pd-cvs@iem.kug.ac.at ) where every cvs-commit gets reported automatically. Sourceforge allows to do this but don't ask me how.
j#|@
nobody should ever check into a module they do not own/maintain. if they do they need to be politely reminded of this and/or reprimanded. otherwise the stability/state of the module can not be known by the maintainer, which is really bad.
-joschi
On Mon, 2002-11-18 at 17:31, Yves Degoyon wrote:
hi,
i've got this dilemna right now :
i agree for distributing my externals with Demudi but i'd rather not store them in the CVS repository.. why? hum, i don't want to support objects which have been modified without a prior agreement and a code review, leaving them in CVS is letting the things go that way...
i'd rather not.
cheers,
sevy/yves
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
On Mon, 2002-11-18 at 18:51, Josh Steiner wrote:
nobody should ever check into a module they do not own/maintain.
arg, i mistyped. i meant to say : "nobody should ever check into a module they do not own/maintain without clearing it with the module owner first."
if they do they need to be politely reminded of this and/or reprimanded. otherwise the stability/state of the module can not be known by the maintainer, which is really bad.
-joschi
On Mon, 2002-11-18 at 17:31, Yves Degoyon wrote:
hi,
i've got this dilemna right now :
i agree for distributing my externals with Demudi but i'd rather not store them in the CVS repository.. why? hum, i don't want to support objects which have been modified without a prior agreement and a code review, leaving them in CVS is letting the things go that way...
i'd rather not.
cheers,
sevy/yves
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
-- _____________________________________________________ you need more drum'n'bass -- http://mp3.com/vitriolix
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list