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

[Hin-Tak Leung]

--- On Sat, 16/3/13, peter dalgaard <pdalgd at gmail.com> wrote:

> On Mar 16, 2013, at 02:50 , Hin-Tak Leung wrote:
> 
> > 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.
> 
> It is not a design goal in any project that I know of, that
> svn exports should be equivalent to distribution tarballs.
> In simple projects, that might be the case, but requiring a
> "make dist" step is quite common before the final shipment.

Yes and no. Many projects much larger than R have a "make dist" target. However, I don't know of any where they make it a feature and a design goal and actively go forward that a 'make dist' tar ball differs substantially in functionality from a snapshot close to the release revision, and also actively make sure that a snapshot does not work.

Try name one.

Even if you can name one other such project, is that honestly good practice to emulate?

> An actual design goal has been to ensure that snapshot
> builds carry an SVN revision number so that we can detect
> whether issues are reported on versions prior to a known
> fix. This is done via an "svn info" command because that was
> the path of least resistance (you can't really e.g. maintain
> the SVN-REVISION file in svn because it would need to change
> on every commit). There's no particular intention to
> hardwire SVN as the source code management tool, but as it
> happens to be what we use, that tiny subsystem of the build
> system has to be specific to SVN.

As is evident, dependence on svn is already hardwired. Look at the issue leading up to this discussion: there were (are, since there isn't a new release yet) code in Matrix, and also elsewhere from a cursory grep, where code paths are conditional on specific version commit numbers, and do different things before/after specific svn revision numbers. 

> The generic point is that you are given access to a working
> tool that is internal to the core R developers. We are not
> putting restrictions on what you do with that access, but if
> you want to play the game by other rules than we do, you
> need to take the consequences. If things don't work and you
> start complaining about them being "broken", steps may be
> taken to make it clearer who broke them.

There is a difference between "unsupported" ("I don't want to spend time hearing about issues arising from going off the beaten path"), versus 'actively discourage going off "beaten" path'. 

Where, of course, "beaten path" is defined by a small group of people, as is "design goal". (it is a feature to break).

> As Jari Oksanen put it recently:
> 
> "I think the rule is that you can do anything as long as you
> don't complain. If you want to complain, you must follow the
> instructions."
> 
> Peter D.
> 
> -- 
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Email: pd.mes at cbs.dk 
> Priv: PDalgd at gmail.com
> 
> 
> 
> 
> 
> 
> 
> 
>