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

Hi,

On Mon, Jan 19, 2015 at 03:31:32PM -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.

-- 
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/7ecb4558/attachment.bin>

On Mon, Jan 19, 2015 at 12:34 PM, Felipe Balbi <balbi at kernel.org>
wrote:
> Hi,
>
> On Mon, Jan 19, 2015 at 03:31:32PM -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.
The community does; R-Core doesn't. See
https://github.com/wch/r-source/wiki for information on workarounds,
and feel free to add your own workarounds for building R on Windows
from a git checkout (if you have such a thing -- get in touch with
Winston and he'd be happy to modify the wiki)
>
> --
> balbi
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 19/01/2015 3:34 PM, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Jan 19, 2015 at 03:31:32PM -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,
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
central repository for everything.

Duncan Murdoch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJUvWy9AAoJEHE2Kz23YMZyHpsH/0qDIdD2ScjvK3HNC9icGhi/
yx0elSt7CuGI1zC35UNRewMHr9VAR+CfGKV6mtwulMKpbbEm6QEED7y6fV3z3g3L
uhW6adCiUBop/Q51SbjkBp30LJ4hjkvLPwuBjJfvjYm2XqbPkf5O1RYVDWgHDWGB
/GIsbHs/VOFDc8As6KzejuiUfL1yVK+SSyU/WaQ5SINRZdVLzDALt9DDOZooH4a8
l4zKGE/z12SfTRH1yaCK6zc5nTwCBCNU++xApAj4yjjw01sryTZQfIAgkUmoQJ2i
HpULugjVVsSvQ9tvs4GoYHHHLoeo5RmZ6/Al0gQMvkm2TSliFWfGi0FaMMXhrfI=f0N3
-----END PGP SIGNATURE-----

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>