hmm, i don't really understand the politics of this thread moving between pd-list, pd-dev, gem-dev and no list at all. i put it back to pd-dev where i think is the appropriate place. i hope this is ok for both of you and there is no sensitive content in your emails.
Mathieu Bouchard wrote:
On Mon, 8 May 2006, Alexandre Castonguay wrote:
ultimatum which simply solidifies positions. I think that the cvs issue is bothering everyone and that the IEM is probably better placed to host it.
I'd rather have everything moved back to IEM, which is also what I said when the CVS left IEM, but now I have a real reason.
did the CVS ever leave the iem? i don't remember that it ever lived there.... (cvs.pd.iem.at has always been an alias for cvs.sourceforge.net; i just made it so i don't have to bother whether the real name is cvs.sf.net or pure-data.cvs.sf.net of whatever)
If IEM doesn't move the CVS this month and SF doesn't improve, then I want
whether SF improves is obviously out of my hand. migrating the CVS from sf to iem is another issue: i do think that it might be worth the efford, however it is certainly nothing i want to do within *this* month.
a relay (for 0-delay anonymous update).
setting up a mirror of the developers' access to sourceforge's CVS at the iem shouldn't be a big problem: by this i mean that we can grant bandwidth and infrastructure; how to make it to be 0-delay i don't know yet, but i guess that we can do that with combined powers.... and even if there was some delay (e.g. 1h) it would at least provide _recent_ changes to the codeset, instead of being frozen at the end of march...
however, the real issue is with developer access: for whatever versioning backend we choose, we have to setup the user database at puredata.info; what i always had in mind was using the portal-users (how you log-in at http://puredata.info) for this; unfortunately the users are currently stored directly in the zope/plone instance instead of a unified backend (ldap) which could be used to authenticate for ssh(cvs)/webdav(svn)/whatever/... access.
obviously this is also a security issue, so i have to insist on a "clean" solution.
as for subversion vs. cvs, the problem is that i still think that getting the pd repository to svn is (at the very least) a "hard" task. another important issue is, that svn knows nothing about priviliges (you cannot restrict users to read-only in a special branch (or rather subdirectory, as that is how svn handles branches) directly. such privilege separation is currently used in the pd-CVS on sf. i am pretty sure that it is possible by sophisticated usage of the apache-<Limit>, but i have no experience on making it work together smoothly.
a quite cool solution might be the use of zope/plone as the authentication frontend (instead of apache): this would allow for web-configurable user/group settings and very fine grained restrictions on who can access what. however, i have no experience AT ALL whether this could work well (and reliable)
If no-one helps me to set up the relay and I can't get it to work, then I'll have to fork the branch.
as stated above, setting up an (anonymous) mirror should be no problem.
mfg.asdr. IOhannes
On 8 May 2006, at 19:36, IOhannes m zmoelnig wrote:
hmm, i don't really understand the politics of this thread moving between pd-list, pd-dev, gem-dev and no list at all.
Er, I included pd-dev in the cc of my reply, and I only just hit 'reply' on my client, so not sure whether there is any politics I can foresee having to explain.
i put it back to pd-dev where i think is the appropriate place. i hope this is ok for both of you and there is no sensitive content in your emails.
See above, I sometimes tire of copy+pasting pd-dev back to its rightful place in the To: field, so just hit reply.
Is there anything we can do about setting the reply-to field? sorry to be OT>
d
Hi Iohannes,
another important issue is, that svn knows nothing about priviliges (you cannot restrict users to read-only in a special branch (or rather subdirectory, as that is how svn handles branches) directly. such privilege separation is currently used in the pd-CVS on sf. i am pretty sure that it is possible by sophisticated usage of the apache-<Limit>, but i have no experience on making it work together smoothly.
i don't think this is true any longer for the current svn series 1.3. It includes the mod_authz_svn module which can be used for path-based authorization.
greetings, Thomas
Thomas Grill schrieb:
Hi Iohannes,
another important issue is, that svn knows nothing about priviliges (you cannot restrict users to read-only in a special branch (or rather subdirectory, as that is how svn handles branches) directly. such privilege separation is currently used in the pd-CVS on sf. i am pretty sure that it is possible by sophisticated usage of the apache-<Limit>, but i have no experience on making it work together smoothly.
i don't think this is true any longer for the current svn series 1.3. It includes the mod_authz_svn module which can be used for path-based authorization.
sorry, i mixed up two things: - mod_authz_svn is for WebDAV access (and allows fine-grained authorization) - the stand-alone server version 1.3 allows the same independently from mod_authz_svn
greetings, Thomas
-
David Plans Casal -
IOhannes m zmoelnig -
Thomas Grill