I agree that the R-Forge system is solid once you have it going but its better if you are Linux based and less attractive if you are Windows based. In particular if the two problems I cited before (use of ssh and the delay) were addressed then together with the key feature of automatic builds that it already has then it would be usable for commits by Windows users.
What I don't agree with is that its easy on Windows if you know ssh. I know ssh and have configured many Linux machines with it but it took me two days to get R-Forge working on a Windows machine since trial and error fiddling involves a delay for each attempt. If you are lucky it will work on your first attempt but if that one fails then you are in for a potentially long series of trial and error attempts potentially taking days. Getting back to the original poster who may have been forgotten in all this, alternatives are switching to Linux and using R-Forge with that (if such a switch in platforms is feasible) or using googlecode (that's the largest repository of R projects outside of CRAN with 237 R projects listed -- it uses https rather than ssh which eliminates all the problems). On Sun, Mar 28, 2010 at 12:34 PM, Henrik Bengtsson <h...@stat.berkeley.edu> wrote: > 5. No https access - only svn+ssh access with private/public keys > > The svn+ssh protocol for SVN commits is a show stopper for people who > never used SVN or ssh authentication keys before. It is easy for > someone who knows how it should work, but quite hard to troubleshoot > if you don't know what to expect. It is hard to help someone get > started without being next to them on their computer. This makes it > hard to convince people who "don't really" care to start using SVN and > r-forge (which would improve overall quality in the long run). > Supporting SVN commits over https would lower this threshold. ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel