On Feb 6, 2011, at 2:28 PM, Alexander Hansen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2/6/11 1:53 PM, Daniel Johnson wrote: >> As we all should know by now, Sourceforge's CVS access went down on Jan 26 >> due to an attack on their servers and is still down now with no estimate of >> when it'll be back. Sourceforge has also indicated that they're considering >> ending CVS access altogether in the near future since its architecture is >> inherently fragile and insecure. Some maintainers have discussed switching >> to something a little less ancient for a while now but inertia is a powerful >> force. :) >> >> So now that our hand is being forced, I decided to just go and do something. >> The maintainers I've talked to would like to use Git or Mercurial (and so >> would I) but after some discussions on IRC I've come to the conclusion that >> our best choice is Subversion. Now wait, don't yell at me! Let me explain. >> Fink is a bit different from most projects in that our users have to >> interact with our repository to use fink, either through rsync or cvs. So, >> we need something that is easy for our users to use. >> >> Subversion has two big advantages going for it from a user's perspective. >> >> 1. It comes standard with the system on 10.5 and later. 10.4 users would >> have to 'fink install svn'. >> >> 2. Sourceforge provides svn access over https on standard port 443, which >> means people can use it behind firewalls. Since most firewalls block >> everything but 80 and 443, svn is really our only choice because it's the >> ONLY service Sourceforge supports over one of those ports. >> >> Subversion also behaves substantially similar to cvs so maintainers won't >> have to learn a whole new way of using the repository. Git and Mercurial >> work differently and would require people used to only cvs to learn a new >> way of doing version control. If maintainers REALLY want to use them, >> git-svn and hg-subversion allow Git and Mercurial to act as svn clients. >> >> gecko2 has been keeping a copy of the sf cvs repository so I was able to >> download that and experiment. Converting it to svn was simple with 'cvs2svn >> --fallback-encoding=utf_8 --retain-conflicting-attic-files'. There are a >> handful of log messages with utf8 text in them, thus the >> --fallback-encoding, and a few cases of files existing in both the Attic and >> the regular tree--a mild form of cvs corruption. cvs2svn worked like a charm >> and I now have a local svn repository with full history preserved. I then >> implemented a selfupdate-svn method for fink. I successfully bootstrapped >> fink, switched to selfupdate-svn, switched to selfupdate-rsync, then >> switched back to svn without a hitch. I can't test switching with cvs, for >> obvious reasons. >> >> There's nothing more that can be done at the moment since both cvs and shell >> access are still down, and we can't enable svn without them. I just wanted >> to put this out there and see what opinions other people had. There would >> need to be other changes made since fink's website is generated from the >> sources in cvs and the package database draws information from there as well. >> >> Daniel >> >> > > The website is just updated via a "cvs update", so that shouldn't be > terribly difficult to handle. And the rsync mirror scripts would need > to switch over as well. > > Would we have the ability easily to regulate commits access on a more > fine-grained level than we're using right now? E.g. to give most > established maintainers the ability to commit and modify their own .info > files but not to modify those of other maintainers? That'd be a useful > additional feature in my opinion, because we could consider broadening > our pool of committers and thereby reduce the backlog on the tracker.
Alas, no. "At this time, SourceForge.net does not provide finer-grained permissions (e.g. restrict access by specific paths within a repository) for Subversion. We will consider implementing fine-grained permissions for our Subversion service based on the feedback we receive from project developers." It looks like all Sourceforge provides is access to the whole repository. That would actually be a step backward from cvs. :/ I guess it would be possible to have a pre-commit-hook script that limited access to certain areas. It would have to look up whether a maintainer had access to a particular file and could veto unauthorized commits. We would have to set that up ourselves. BTW, I hacked fink to use gecko2's cvs copy so that I could test switching between svn and cvs; it works fine. Daniel ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
