Hallo,
I'm starting a new thread from "easy way to download the whole shebang".
The instructions for how to change from CVS to SVN on Sourceforge are here: http://sourceforge.net/docman/display_doc.php?docid=31070&group_id=1#imp...
It's a process involving many steps, but not impossible. One thing to note is that "The migration will be finished within 24 hours. It could be finished in as soon as an hour or two, depending on the size of your CVS repository and the number of projects queued for migration in front of yours."
So if we switch we need to freeze write access to the repo for at least that time, and probably some more time before and after for preparing and testing the transformation.
Side note: One thing we should freeze immediatly is accepting new developers until we either decide to not go SVN, or until the transformation is done.
So what's left as far as I see it is:
1) developer vote:
Should the SF repository switch from CVS to SVN on Sourceforge? [ ] yes [ ] no
2) sort out techical issues with branches, tags etc.
3) find someone (incl. admins!) who volunteers to do the import. I would volunteer but I wouldn't want to do this completely alone.
4) agree on date
5) do it.
Ciao
On 13 Aug 2006, at 08:56, Frank Barknecht wrote:
Should the SF repository switch from CVS to SVN on Sourceforge?
[X ] yes [ ] no
- find someone (incl. admins!) who volunteers to do the import. I
would volunteer but I wouldn't want to do this completely alone.
I maintain a couple of (very) simple SVN repositories, and I'm probably not the best candidate in terms of admin experience, but I will help if needed.
d
Frank Barknecht wrote:
Hallo,
- 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?
- 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) (the repository basically consists of a lot of small packages which all have their independent release cycles)
for pd/pd-devel i suggest 2 main branches in parallel (e.g. /pd/trunk/ and /pd/devel/ instead of /pd/branches/devel
- 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)
mfg.adsr- .IOhannes
agree on date
do it.
Ciao
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
- 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.
- 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.
- 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 wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
- 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 some other modules too, like iemlib,...
personally i would favour a acl-less system
- 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.
well the trunk/tags/branches layout in svn is really just a recommendation. we need not stick to it.
however, you are right that my proposal would break any BIG build system.
so probably a big /trunk and a big /tags would not be so bad (with /trunk/pd and /trunk/pd-devel in parallel) for most externals there are no real "branches" so we could skip this. and whenever an external (or pd) makes a release, a "shallow" copy would be made into "/tags" (or "/releases" which i prefer)
I cannot really comment on how to best deal with the branches of Pd's sources.
- 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. ;)
sounds like a good idea. so anybody who wants to join the migration from cvs to svn should come to graz in september ;-)
mfg.adsr. IOhannes
On Aug 13, 2006, at 11:56 AM, Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
- 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
- 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.
- 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 PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
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.serve...
Luke
On 8/21/06, Hans-Christoph Steiner hans@eds.org 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:
- 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
- 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.
- 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 PD-dev@iem.at 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 PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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 hans@eds.org 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:
- 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
- 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.
- 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 PD-dev@iem.at 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 PD-dev@iem.at 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
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
i am all for it, but: does sourceforge already implement some kind of acl for svn? or can we live without acl's?
According to the Site Docs, "no means is provided to limit access to a repository on a per-path basis" for Subversion. This seems to be planned, but as we know Sourceforge, one shouldn't hold his/her breath.
Ciao
i am all for it, but: does sourceforge already implement some kind of acl for svn? or can we live without acl's?
According to the Site Docs, "no means is provided to limit access to a repository on a per-path basis" for Subversion. This seems to be planned, but as we know Sourceforge, one shouldn't hold his/her breath.
well, the pd repository doesn't need to be located at sourceforge ... i mean, the plone site is located on an iem server, so, if someone takes the work of converting a cvs repository to a subversion, why not move the repository server? currently two features of sf are used ... the cvs and the tracker ... imo, it wouldn't be a bad idea, to put the svn server as well as a decent bug tracker (bugzilla/mantis/whatever) onto the puredata.info server and abandon sourceforge ... not sure, if the iem / the puredata.info server has enough resources, but at least no one would complain about sourceforge any more :)
tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
You can play a shoestring if you're sincere John Coltrane
Tim Blechmann wrote:
i am all for it, but: does sourceforge already implement some kind of acl for svn? or can we live without acl's?
According to the Site Docs, "no means is provided to limit access to a repository on a per-path basis" for Subversion. This seems to be planned, but as we know Sourceforge, one shouldn't hold his/her breath.
well, the pd repository doesn't need to be located at sourceforge ... i mean, the plone site is located on an iem server, so, if someone takes the work of converting a cvs repository to a subversion, why not move the repository server? currently two features of sf are used ... the cvs and the tracker ... imo, it wouldn't be a bad idea, to put the svn server as well as a decent bug tracker (bugzilla/mantis/whatever) onto the puredata.info server and abandon sourceforge ... not sure, if the iem / the puredata.info server has enough resources, but at least no one would complain about sourceforge any more :)
they biggest problem i see is the user migration. unfortunately, all the puredata.info users are currently stored within the zope-db; it they were stored in an ldap-server, the user credentials could be used for cvs/svn/git/... authentication.
i currently don't know how to migrate the users from zodb to ldap.
mf.asdr. IOhannes
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
well, the pd repository doesn't need to be located at sourceforge ... i mean, the plone site is located on an iem server, so, if someone takes the work of converting a cvs repository to a subversion, why not move the repository server?
Of course IEM would be a fantastic solution in the long run. But currently we face two problems:
1) CVS sucks. 2) Sourceforge sucks.
In my view, both problems aren't directly related: We could solve 1) now by moving to SVN and live with 2) for a while longer, until we can also solve 2) by moving to IEM or similar.
Ciao
On 13 Aug 2006, at 20:05, Frank Barknecht wrote:
In my view, both problems aren't directly related: We could solve 1) now by moving to SVN and live with 2) for a while longer, until we can also solve 2) by moving to IEM or similar.
Actually, svn export is quite reliable. So if we migrate to svn, there shouldn't be any difficulty in moving the physical server location later on.
On an earlier comment, I also think /externals/zexy/trunk instead of / trunk/externals/zexy would be better, but taking care of that after the big move with svn mv commands shouldn't be a problem? In my experience, it pays off to lay directories for an svn repo as you'll want to add them.
In any case, I've recently converted a (small) cvs SF project to svn and it went perfectly fine.
But, I can't be in Graz in September ;-)
d
-
David Plans Casal -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Luke Iannini (pd) -
Tim Blechmann