I'll quantify the first part - R is perhaps the only public software project hosted on a subversion repository for which the result of 'svn export ...' does not build. Not only that it does not build, but make it a feature that it does not build.
Very few other projects actively try to go in that direction. --- On Fri, 15/3/13, Hin-Tak Leung <hintak_le...@yahoo.co.uk> wrote: > 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
