The decision to actively discourage non-subsersion usage of snapshot build is already made (r62183). So I am just here to register a differing opinion.
- it is not about subversion vs other-version-control-tools. There are two parts of R's dev build process which requires an active network connection - tools/rsync-recommended and capturing `svn info` into R's headers. The former can be overridden with "./configure --with-recommended-packages=no". A few changes had been made in the last 6 months to make the latter mandatory. It used to be optional. --- there are genuine needs for testing snapshots in a non-networked minimalist environment - e.g. banks or telecom industries - where one wants a "standardised host" build, and often it means an "outdated host"; or in a virtual machine environment - which are non-networked for security reasons, and also do not have tools beyond necessary for compiling and building. This is quite a common scenario. --- AFAIK, 6 months ago, a snapshot copied to an non-networked host will build with "./configure --with-recommended-packages=no". Of course copying those recommended package tar balls across would be nicer. This is sadly no longer the case. - dependent on `svn info` and sitting on top of a svn checkout possibly also affects cross-compiling. But then, it is not clear whether it is still possible to cross-compile R, since quite a few changes have been made to remove the capability of cross-compiling R for windows on unix hosts in the last few years. - testing dev snapshots is about trying things and fixing bugs before release. Making it difficult for non-core people to "try", seem to go against that ethos. If that's the case, maybe the repository could be closed off to anonymous check outs altogether, just to make it clear that testing snapshots before releases or even close to release, is not welcomed. Just a thought. - although the official repository of the "main" linux kernel branch is git-based, there are mercurial mirrors; AFAIK the digital video broadcasting hardware support of the linux kernel is officially in mercurial repositories, but have git mirrors; likewise much of Xorg's is in mercurial but have git mirrors. I haven't heard of any much bigger public projects than R where some actively discourage others. - To be honest r62183 itself is probably a good reason to move away from server-side repositories to distributed repositories (hg/git/arch/bzr). Local enhancements - i.e. an in-house fork - some of which are never going upstream, such as a local revert of r62183 (or a local revert of any other upstream commits) is one reason why some have distributed repositories. Lastly, a minor grip. The current head of the HK government is probably sometimes called "HK Leung", just as some might call a certain old lady "UK Windsor" and a certain black person "US Obama". ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
