[PD-dev] CVS/SVN @ iem (was Re: [GEM-dev] CVS...)

[IOhannes m zmoelnig]

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