On Feb 6, 2011, at 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.
For anonymous access, I suspect it's the CVS program, rather than the protocol, which is insecure. Also, the SVN backing stores are not much more robust than CVS - they simply bundle the same change information into atomic commits (rather than the CVS per-file history). > Some maintainers have discussed switching to something a little less > ancient for a while now but inertia is a powerful force. :) ... which is why I support moving something distributed. > 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'. Agreed. > 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. This supposes that we want to stay with SourceForge for version control. Their issue tracker doesn't interact with version control (to my knowledge), so there isn't any value-add that ties those services together (e.g. a commit message automatically closes a given tracker item when the tracker ID is mentioned after "closes:".) Mercurial and Git are available over HTTP on other version control hosting sites. > 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. Turning that around, Git allows you to set up a CVS pserver daemon which could be used for bootstrapping a Fink installation (if rsync is not desired). Again, maybe not an option for SourceForge, but part of the attractiveness of distributed SCM systems is that you can easily move to another hosting system if things go awry (temporarily or permanently). I dunno, I won't complain (too loudly, anyway) if the consensus is SVN, but if we're looking at alternatives, we might want to look at things beyond just what SourceForge offers. ------------------------------------------------------------------------------ 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
