[Rd] the case of building R snapshot without svn nor network connection.

[Hin-Tak Leung]

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_leung at 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".
>