I'd say the next steps are for someone to:
a) set up a test respository and try the conversion
b) propose a layout of trunks and branches (IIRC, there is some
choice in the matter).
SourceForge's SVN does not currently have ACLs, and AFAIK, no one is
volunteering to host SVN. IEM has been mentioned, but I am not sure
that IOhannes really wants more sysadmin work.
.hc
On Sep 19, 2006, at 9:39 PM, Luke Iannini (pd) wrote:
Any updates on this?
I promise to take (one of) the official role(s) of "SVN newbie help"
to all that need it after (if?) the change takes place : ).
Regarding the user accounts, Zope seems to have XML export for objects
http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/
UsingZope.stx.
That could perhaps be parsed for migrating to LDAP? (if this is
completely off base, sorry : ), I only skimmed quickly through.)
Finally, regarding the CVS ACLs, these should be easily translatable
to Subversion Per-directory Access Control (which does mean we'd have
to run Subversion via Apache). This is covered on pg. 132 of the SVN
Book
http://svnbook.red-bean.com/nightly/en/
svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz.perdir
Luke
On 8/21/06, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote:
On Aug 13, 2006, at 11:56 AM, Frank Barknecht wrote:
> Hallo,
> IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
>
>> Frank Barknecht wrote:
>>
>>> 1) developer vote:
>>>
>>> Should the SF repository switch from CVS to SVN on Sourceforge?
>>> [ ] yes
>>> [ ] no
>>
>> i am all for it, but: does sourceforge already implement some
kind of
>> acl for svn? or can we live without acl's?
>
> Uh, we need to check this. But AFAIK we currently only use the
ACL on
> Miller's branch.
There are a few more ACLs than that:
http://pure-data.cvs.sourceforge.net/pure-data/CVSROOT/avail?
view=markup
This is probably important, so it needs to be sorted before the
transition. If ACLs are in place, then I vote YES, otherwise MAYBE
(there would have to be some more politicing)...
.hc
>>> 2) sort out techical issues with branches, tags etc.
>>
>> for externals i would suggest to split branches on each external
>> separately, (e.g. /externals/zexy/trunk instead of /trunk/
>> externals/zexy
>> or /externals/trunk/zexy)
>
> Yes, I agree with this, but this can be dealt with after The Big
> Change, I suppose. For the externals we also should to take care
not
> to break the extended Build-system. Some changes will be
necessary to
> the Build of course, because of the usual trunk/tags/branches
layout
> in SVN.
>
> I cannot really comment on how to best deal with the branches of
Pd's
> sources.
>
>>> 3) find someone (incl. admins!) who volunteers to do the
import. I
>>> would volunteer but I wouldn't want to do this completely alone.
>>
>> i would volunteer too, however i don't see any advantage in having
>> 2 (or
>> more) persons involved in the migration. (probably when they are
>> at the
>> same terminal, like with XP, then there might be a benefit)
>
> Let's do it mid-September then, when I'm in Graz. ;)
>
> I would actually prefer if someone else than me would do it, as I'm
> not that experienced especially with CVS internals, so I would
gladly
> let you take over.
>
> Ciao
> --
> Frank Barknecht _ ______footils.org_
__goto10.org__
>
> _______________________________________________
> PD-dev mailing list
> [email protected]
> http://lists.puredata.info/listinfo/pd-dev
---------------------------------------------------------------------
---
Using ReBirth is like trying to play an 808 with a long stick. -
David Zicarelli
_______________________________________________
PD-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
_______________________________________________
PD-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
