-----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. - -- Alexander Hansen, Ph.D. Fink User Liaison -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1O9mwACgkQB8UpO3rKjQ9VwwCghglK/uLmUxUp3hGa+EpVpI0g psMAn0q7kLaldeptyVic2tSZvcX0wFn/ =Tnju -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ 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
