R devel - Jan 2015 - [PATCH] Makefile: add support for git svn clones

Hi,

On Mon, Jan 19, 2015 at 03:44:45PM -0500, Duncan Murdoch
wrote:
> >>>>> git has an interface for cloning SVN repositories into
git
> >>>>>  which some users might decide to use. For those
users'
> >>>>> surprise, the repository will always fail to build on
> >>>>> svnonly target and it will exit early.
> >>>>> 
> >>>>> The problem is simple enough to fix by just checking
if a
> >>>>> .git directory exists in top_builddir and, if so, call
git
> >>>>> svn info insstead of svn info.
> >>>>> 
> >>>> 
> >>>> I think we are unlikely to accept this change.  Nobody in
R
> >>>> Core uses git this way, so it would never be tested, and
> >>>> would likely soon fail.
> >>> 
> >>> it will be tested by anybody using git svn clone, right ?
> >>> 
> >>>> Indeed, it already fails if someone were to try it on
> >>>> Windows, since you didn't patch the makefiles for that
> >>>> platform.
> >>> 
> >>> yeah, sorry about that, I wasn't aware there were
> >>> windows-specific Makefiles with duplicated logic in the
> >>> repository.
> >>> 
> >>>> The R sources are kept in an SVN repository, and as long
as
> >>>> that's true, we're only likely to support direct
SVN access.
> >>> 
> >>> Fair enough. But don't you think it's a bit odd to
couple the
> >>> repository compilation with the availability of a specific SCM
> >>> tool ?
> >>> 
> >>> I mean, R just won't build unless you have svn info
available,
> >>> I think that's pretty odd. Printing a warning would be
another
> >>>  possibility, but exitting build is almost an overreaction.
> >> 
> >> That's just false.  Build from a tarball, and you can store it
> >> anyway you like.
> > 
> > I'm talking about the SVN repository. Building from a tarball
> > prevents me from tracking R's revisions, don't you think ? But
as I
> > said, if the community doesn't want to support a git svn clone,
> > that's all fine and dandy.
> > 
> 
> So why not make your patch locally, and publish it for any other git
> user to incorporate?  If some change to the master copy breaks it,
heh, that's what I'll have to do of course.
> you'll see it, and you'll fix it.  Then everyone's happy.  One
of the
> purported advantages of git is the fact that it doesn't require a
it's not purported, it's a real advantage, but this is not subject of
discussion in this forum
> central repository for everything.
Right, that's all fine, it'll still be an "unofficial" change.

I just thought that such a small patch which causes no visible change to
SVN users and allow for git users to build R would be acceptable, but if
it isn't, that's fine too.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<https://stat.ethz.ch/pipermail/r-devel/attachments/20150119/00814392/attachment.bin>

On Mon, Jan 19, 2015 at 1:00 PM, Felipe Balbi <balbi at kernel.org>
wrote:
> I just thought that such a small patch which causes no visible change to
> SVN users and allow for git users to build R would be acceptable, but if
> it isn't, that's fine too.
Felipe ---

It would appear that you are unaware that you are walking a minefield
of entrenched positions and personality conflicts.  For those like
myself who are mystified by the positions taken in this thread, a
partial back story may be helpful.

In 2012, Han-Tak Leung reported a problem compiling the development
version of R that he had checked out using git's svn compability
feature: https://stat.ethz.ch/pipermail/r-devel/2012-October/065133.html

In 2013, Brian Ripley applied a patch with the comment "trap HK Leung
misuse" explicitly to prevent users from being able to do this:
https://github.com/wch/r-source/commit/4f13e5325dfbcb9fc8f55fc6027af9ae9c7750a3

Shortly thereafter, Han-Tak tried to start discussion on this list
about that patch, suggesting that preventing the use of non-SVN
mirrors reduced the frequency with which development versions would be
tested:
https://stat.ethz.ch/pipermail/r-devel/2013-March/066128.html

The opinions expressed on the thread were universally against Leung.
Peter Dalgaard summarized as:
"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."
https://stat.ethz.ch/pipermail/r-devel/2013-March/066131.html

As a newcomer hoping to contribute to R who had already encountered
this same compilation issue and considered it was a bug, I am
astounded to learn that it is instead desired and intentional
behavior.

--nate

On Mon, Jan 19, 2015 at 3:13 PM, Nathan Kurz <nate at verse.com>
wrote:
> On Mon, Jan 19, 2015 at 1:00 PM, Felipe Balbi <balbi at kernel.org>
wrote:
>> I just thought that such a small patch which causes no visible change
to
>> SVN users and allow for git users to build R would be acceptable, but
if
>> it isn't, that's fine too.
>
> Felipe ---
>
> It would appear that you are unaware that you are walking a minefield
> of entrenched positions and personality conflicts.  For those like
> myself who are mystified by the positions taken in this thread, a
> partial back story may be helpful.
>
> In 2012, Han-Tak Leung reported a problem compiling the development
> version of R that he had checked out using git's svn compability
> feature: https://stat.ethz.ch/pipermail/r-devel/2012-October/065133.html
>
You forgot to mention that, in February of 2013, Hin-Tak reported that
Matrix did not build with the R trunk since October, 2012; but it
turned out not to build because he didn't have a subversion checkout.
https://mailman.stat.ethz.ch/pipermail/r-devel/2013-February/065858.html
> In 2013, Brian Ripley applied a patch with the comment "trap HK Leung
> misuse" explicitly to prevent users from being able to do this:
>
https://github.com/wch/r-source/commit/4f13e5325dfbcb9fc8f55fc6027af9ae9c7750a3
>
> Shortly thereafter, Han-Tak tried to start discussion on this list
> about that patch, suggesting that preventing the use of non-SVN
> mirrors reduced the frequency with which development versions would be
> tested:
> https://stat.ethz.ch/pipermail/r-devel/2013-March/066128.html
>
> The opinions expressed on the thread were universally against Leung.
> Peter Dalgaard summarized as:
> "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."
> https://stat.ethz.ch/pipermail/r-devel/2013-March/066131.html
>
> As a newcomer hoping to contribute to R who had already encountered
> this same compilation issue and considered it was a bug, I am
> astounded to learn that it is instead desired and intentional
> behavior.
>
> --nate
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


-- 
Joshua Ulrich  |  about.me/joshuaulrich
FOSS Trading  |  www.fosstrading.com

On 19/01/2015 4:13 PM, Nathan Kurz wrote:
> On Mon, Jan 19, 2015 at 1:00 PM, Felipe Balbi <balbi at kernel.org>
wrote:
>> I just thought that such a small patch which causes no visible change
to
>> SVN users and allow for git users to build R would be acceptable, but
if
>> it isn't, that's fine too.
> 
> Felipe ---
> 
> It would appear that you are unaware that you are walking a minefield
> of entrenched positions and personality conflicts.  For those like
> myself who are mystified by the positions taken in this thread, a
> partial back story may be helpful.
I don't think there should be anything particularly mystifying here.
The people who would have to maintain the patch can't test it.  The
people who can test it can apply it themselves.  It's just a matter of
efficiency.  There's a very easy way for you to use the svn checkout,
and that is to check it out using svn.  If you want to use a tool that's
never tested, then you're on your own.

In another reply to you, Joshua pointed out one of the problems that
using untested tools causes.  It wasted a lot of Hin-Tak's and other
people's time.  That time could have been spent in a productive way, but
it wasn't.

Duncan Murdoch

> 
> In 2012, Han-Tak Leung reported a problem compiling the development
> version of R that he had checked out using git's svn compability
> feature: https://stat.ethz.ch/pipermail/r-devel/2012-October/065133.html
> 
> In 2013, Brian Ripley applied a patch with the comment "trap HK Leung
> misuse" explicitly to prevent users from being able to do this:
>
https://github.com/wch/r-source/commit/4f13e5325dfbcb9fc8f55fc6027af9ae9c7750a3
> 
> Shortly thereafter, Han-Tak tried to start discussion on this list
> about that patch, suggesting that preventing the use of non-SVN
> mirrors reduced the frequency with which development versions would be
> tested:
> https://stat.ethz.ch/pipermail/r-devel/2013-March/066128.html
> 
> The opinions expressed on the thread were universally against Leung.
> Peter Dalgaard summarized as:
> "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."
> https://stat.ethz.ch/pipermail/r-devel/2013-March/066131.html
> 
> As a newcomer hoping to contribute to R who had already encountered
> this same compilation issue and considered it was a bug, I am
> astounded to learn that it is instead desired and intentional
> behavior.
> 
> --nate
>