Re: [Rd] SVN vs DVCS
> Felix Andrews > on Wed, 26 May 2010 11:20:12 +1000 writes: > On second thoughts it is really none of my business how the R sources > are managed. > But I would encourage package developers and/or r-forge maintainers to > consider these systems. Thank you, Felix, for the compilation of these alternatives. One very relevant piece of information that you've not added, is, how easily one could *move* from svn to such a system (including the full history of every file with revision numbers, log messages, etc), and .. for R-forge, e.g., which of these provide nice and flexible tools (as svn does) for an automatic web interface to inspect file histories, differences, etc. Regards, Martin ( maintainer of svn.r-project.org ) > Regards > -Felix > On 26 May 2010 10:29, Felix Andrews wrote: >> Hi, >> >> Just wondering whether anyone had thought about moving the R sources >> to a "distributed" version control system such as Bazaar, Git or >> Mercurial. These new generation systems make it easier to work on >> feature branches, allow working offline, are very fast, etc. >> >> Some projects that have moved to Git are >> Linux Kernel >> Perl >> Ruby on Rails >> ... >> http://en.wikipedia.org/wiki/Git_(software) >> >> Some projects that have moved to Bazaar (bzr) are >> Ubuntu >> MySQL >> Inkscape >> ... >> http://en.wikipedia.org/wiki/Bazaar_(software) >> >> Some projects that have moved to Mercurial (hg) are >> Mozilla >> Octave >> Python >> ... >> http://en.wikipedia.org/wiki/Mercurial_(software) >> >> Joel Spolky's take on it: >> http://www.joelonsoftware.com/items/2010/03/17.html >> >> Regards >> -Felix >> >> -- >> Felix Andrews / 安福立 >> Postdoctoral Fellow >> Integrated Catchment Assessment and Management (iCAM) Centre >> Fenner School of Environment and Society [Bldg 48a] >> The Australian National University >> Canberra ACT 0200 Australia >> M: +61 410 400 963 >> T: + 61 2 6125 4670 >> E: felix.andr...@anu.edu.au >> CRICOS Provider No. 00120C >> -- >> http://www.neurofractal.org/felix/ >> > -- > Felix Andrews / 安福立 > Postdoctoral Fellow > Integrated Catchment Assessment and Management (iCAM) Centre > Fenner School of Environment and Society [Bldg 48a] > The Australian National University > Canberra ACT 0200 Australia > M: +61 410 400 963 > T: + 61 2 6125 4670 > E: felix.andr...@anu.edu.au > CRICOS Provider No. 00120C > -- > http://www.neurofractal.org/felix/ > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Indexing bug?
Is this expected behaviour?
x <- factor(c("c", "b", "a","c"))
results <- c(c=4, b=5)
results[x]
giving
> results[x]
bc
NA54 NA
(i.e. it appears to give results[levels(x)]
whereas results[as.character(x)] does what I expected:
as.character(x)
results[as.character(x)]
> as.character(x)
[1] "c" "b" "a" "c"
> results[as.character(x)]
cb c
45 NA4
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Indexing bug?
On Wed, May 26, 2010 at 3:27 PM, Duncan Murdoch
wrote:
> Is this expected behaviour?
>
> x <- factor(c("c", "b", "a","c"))
> results <- c(c=4, b=5)
> results[x]
>
> giving
>
>> results[x]
> b c
> NA 5 4 NA
>
> (i.e. it appears to give results[levels(x)]
I would say it gives
results[as.numeric(x)]
and it's not clear if that is less "expected". E.g., what happens if
results has no names? results[as.numeric(x)] would still work, but not
results[as.character(x)].
Factors have a dual nature (character labels vs numeric codes), and
when forced to choose, I think it's reasonable to choose the solution
which works more generally.
-Deepayan
>
>
> whereas results[as.character(x)] does what I expected:
>
> as.character(x)
> results[as.character(x)]
>
>> as.character(x)
> [1] "c" "b" "a" "c"
>> results[as.character(x)]
> c b c
> 4 5 NA 4
>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Indexing bug?
G'day Duncan, On Wed, 26 May 2010 05:57:38 -0400 Duncan Murdoch wrote: > Is this expected behaviour? Yes, according to the answer that this poster https://stat.ethz.ch/pipermail/r-devel/2008-March/048674.html got. Indeed, the help page of '[' states: The index object i can be numeric, logical, character or empty. Indexing by factors is allowed and is equivalent to indexing by the numeric codes (see factor) and not by the character values which are printed (for which use [as.character(i)]). Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVN vs DVCS
Note that one can also use any of the dvcs systems without actually moving from svn by using the dvcs (or associated extension/addon) as an svn client or by using it on an svn checkout. On Wed, May 26, 2010 at 5:44 AM, Martin Maechler wrote: >> Felix Andrews >> on Wed, 26 May 2010 11:20:12 +1000 writes: > > > On second thoughts it is really none of my business how the R sources > > are managed. > > But I would encourage package developers and/or r-forge maintainers to > > consider these systems. > > Thank you, Felix, for the compilation of these alternatives. > > One very relevant piece of information that you've not added, > is, how easily one could *move* from svn to such a system > (including the full history of every file with revision numbers, > log messages, etc), > and .. for R-forge, e.g., which of these provide nice and > flexible tools (as svn does) for an automatic web interface to > inspect file histories, differences, etc. > > Regards, > Martin ( maintainer of svn.r-project.org ) > > > Regards > > -Felix > > > On 26 May 2010 10:29, Felix Andrews wrote: > >> Hi, > >> > >> Just wondering whether anyone had thought about moving the R sources > >> to a "distributed" version control system such as Bazaar, Git or > >> Mercurial. These new generation systems make it easier to work on > >> feature branches, allow working offline, are very fast, etc. > >> > >> Some projects that have moved to Git are > >> Linux Kernel > >> Perl > >> Ruby on Rails > >> ... > >> http://en.wikipedia.org/wiki/Git_(software) > >> > >> Some projects that have moved to Bazaar (bzr) are > >> Ubuntu > >> MySQL > >> Inkscape > >> ... > >> http://en.wikipedia.org/wiki/Bazaar_(software) > >> > >> Some projects that have moved to Mercurial (hg) are > >> Mozilla > >> Octave > >> Python > >> ... > >> http://en.wikipedia.org/wiki/Mercurial_(software) > >> > >> Joel Spolky's take on it: > >> http://www.joelonsoftware.com/items/2010/03/17.html > >> > >> Regards > >> -Felix __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] segfault on 2.11.0 with large POSIXct vector using as.character
Running "as.character" on a large POSIXct causes a segfault on my 2.11 (2010-04-22) install. Seems to crash at around 9e4 ... on OSX and Ubuntu at least. > invisible(as.character(Sys.time()+1:7e4)) > invisible(as.character(Sys.time()+1:8e4)) > invisible(as.character(Sys.time()+1:9e4)) Error: segfault from C stack overflow > invisible(as.character(Sys.time()+1:5e5)) Error: segfault from C stack overflow Thanks, Jeff > sessionInfo() R version 2.11.0 (2010-04-22) x86_64-apple-darwin10.2.0 locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base > sessionInfo() R version 2.11.0 (2010-04-22) i486-pc-linux-gnu locale: [1] LC_CTYPE=en_US.utf8 LC_NUMERIC=C [3] LC_TIME=en_US.utf8LC_COLLATE=en_US.utf8 [5] LC_MONETARY=C LC_MESSAGES=en_US.utf8 [7] LC_PAPER=en_US.utf8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base > -- Jeffrey Ryan jeffrey.r...@insightalgo.com ia: insight algorithmics www.insightalgo.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] segfault on 2.11.0 with large POSIXct vector using as.character
On my Vista system there is no seg fault: > invisible(as.character(Sys.time()+1:5e5)) > win.version() [1] "Windows Vista (build 6002) Service Pack 2" > R.version.string [1] "R version 2.11.0 Patched (2010-04-26 r51822)" On Wed, May 26, 2010 at 7:29 AM, Jeff Ryan wrote: > Running "as.character" on a large POSIXct causes a segfault on my 2.11 > (2010-04-22) install. Seems to crash at around 9e4 ... on OSX and Ubuntu at > least. > >> invisible(as.character(Sys.time()+1:7e4)) >> invisible(as.character(Sys.time()+1:8e4)) >> invisible(as.character(Sys.time()+1:9e4)) > Error: segfault from C stack overflow > > >> invisible(as.character(Sys.time()+1:5e5)) > Error: segfault from C stack overflow > > Thanks, > Jeff > >> sessionInfo() > R version 2.11.0 (2010-04-22) > x86_64-apple-darwin10.2.0 > > locale: > [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > >> sessionInfo() > R version 2.11.0 (2010-04-22) > i486-pc-linux-gnu > > locale: > [1] LC_CTYPE=en_US.utf8 LC_NUMERIC=C > [3] LC_TIME=en_US.utf8 LC_COLLATE=en_US.utf8 > [5] LC_MONETARY=C LC_MESSAGES=en_US.utf8 > [7] LC_PAPER=en_US.utf8 LC_NAME=C > [9] LC_ADDRESS=C LC_TELEPHONE=C > [11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C > > attached base packages: > [1] stats graphics grDevices utils datasets methods base >> > > -- > Jeffrey Ryan > jeffrey.r...@insightalgo.com > > ia: insight algorithmics > www.insightalgo.com > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Indexing bug?
Duncan Murdoch wrote:
Is this expected behaviour?
x <- factor(c("c", "b", "a","c"))
results <- c(c=4, b=5)
results[x]
giving
> results[x]
bc
NA54 NA
(i.e. it appears to give results[levels(x)]
Thanks to all for pointing out my misinterpretation.It's clearly not
a bug.
Duncan Murdoch
whereas results[as.character(x)] does what I expected:
as.character(x)
results[as.character(x)]
> as.character(x)
[1] "c" "b" "a" "c"
> results[as.character(x)]
cb c
45 NA4
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] segfault on 2.11.0 with large POSIXct vector using as.character
Jeff Ryan wrote: Running "as.character" on a large POSIXct causes a segfault on my 2.11 (2010-04-22) install. Seems to crash at around 9e4 ... on OSX and Ubuntu at least. This has been fixed for a while in R-patched. The 2.11.1 release on Monday should be fine. Apparently people aren't running the betas/release candidates. You really should run the test versions to flush out bugs. If you'd run the pre-release versions of 2.11.0, this bug would likely have been found before release. The standard tests can miss things; the advantage of open source is there are many eyes looking for bugs. But if those eyes are closed, the model doesn't work. Duncan Murdoch invisible(as.character(Sys.time()+1:7e4)) invisible(as.character(Sys.time()+1:8e4)) invisible(as.character(Sys.time()+1:9e4)) Error: segfault from C stack overflow invisible(as.character(Sys.time()+1:5e5)) Error: segfault from C stack overflow Thanks, Jeff sessionInfo() R version 2.11.0 (2010-04-22) x86_64-apple-darwin10.2.0 locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base sessionInfo() R version 2.11.0 (2010-04-22) i486-pc-linux-gnu locale: [1] LC_CTYPE=en_US.utf8 LC_NUMERIC=C [3] LC_TIME=en_US.utf8LC_COLLATE=en_US.utf8 [5] LC_MONETARY=C LC_MESSAGES=en_US.utf8 [7] LC_PAPER=en_US.utf8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] segfault on 2.11.0 with large POSIXct vector using as.character
> > > This has been fixed for a while in R-patched. The 2.11.1 release on Monday > should be fine. > Apparently people aren't running the betas/release candidates. You really > should run the test versions to flush out bugs. If you'd run the > pre-release versions of 2.11.0, this bug would likely have been found before > release. The standard tests can miss things; the advantage of open source > is there are many eyes looking for bugs. But if those eyes are closed, the > model doesn't work. > I'd say it does work, and did. As far as catching before release, that sounds great, as great as having no bugs. I am not too sure that my tests could have caught a bug that the got passed the R tests though, so passing along a segfault issue to those who might know the source better seemed prudent -- even if I could only have the time to test against the released version. Thanks for the fix! Jeff > Duncan Murdoch > > >> >>> invisible(as.character(Sys.time()+1:7e4)) >>> invisible(as.character(Sys.time()+1:8e4)) >>> invisible(as.character(Sys.time()+1:9e4)) >>> >>> >> Error: segfault from C stack overflow >> >> >> >> >>> invisible(as.character(Sys.time()+1:5e5)) >>> >>> >> Error: segfault from C stack overflow >> >> Thanks, >> Jeff >> >> >> >>> sessionInfo() >>> >>> >> R version 2.11.0 (2010-04-22) >> x86_64-apple-darwin10.2.0 >> >> locale: >> [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 >> >> attached base packages: >> [1] stats graphics grDevices utils datasets methods base >> >> >> >> >>> sessionInfo() >>> >>> >> R version 2.11.0 (2010-04-22) >> i486-pc-linux-gnu >> >> locale: >> [1] LC_CTYPE=en_US.utf8 LC_NUMERIC=C >> [3] LC_TIME=en_US.utf8LC_COLLATE=en_US.utf8 >> [5] LC_MONETARY=C LC_MESSAGES=en_US.utf8 >> [7] LC_PAPER=en_US.utf8 LC_NAME=C >> [9] LC_ADDRESS=C LC_TELEPHONE=C >> [11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C >> >> attached base packages: >> [1] stats graphics grDevices utils datasets methods base >> >> >> > > -- Jeffrey Ryan jeffrey.r...@insightalgo.com ia: insight algorithmics www.insightalgo.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVN vs DVCS
I'm not necessarily advocating a migration; probably an administrative nightmare, and everyone involved would be forced to learn new stuff... I was just enthusing because I recently started using a DVCS for the first time. On 26 May 2010 21:16, Gabor Grothendieck wrote: > Note that one can also use any of the dvcs systems without actually > moving from svn by using the dvcs (or associated extension/addon) as > an svn client or by using it on an svn checkout. Yes, that's a very good point (although in my experience it takes a very long time to do the initial download of the SVN repository). I'm not an expert on these systems, but I imagine the main downside (other than speed) of having SVN upstream is that you have to keep the history linear, and so e.g can't collaborate on feature branches this way. But yeah, worth a go. > > On Wed, May 26, 2010 at 5:44 AM, Martin Maechler > wrote: >>> Felix Andrews >>> on Wed, 26 May 2010 11:20:12 +1000 writes: >> >> > On second thoughts it is really none of my business how the R sources >> > are managed. >> > But I would encourage package developers and/or r-forge maintainers to >> > consider these systems. >> >> Thank you, Felix, for the compilation of these alternatives. >> >> One very relevant piece of information that you've not added, >> is, how easily one could *move* from svn to such a system >> (including the full history of every file with revision numbers, >> log messages, etc), Indeed... here is the basic process for migrating to Git http://www.jonmaddox.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/ This will keep the branches, tags, full history, with SVN revision numbers added to the log messages (if you leave off the --no-metadata argument). However, the actual commit ids you would use in git log / git diff / etc will not be the same as the old SVN ids. In fact git uses hash strings rather than numbers, and bazaar uses sequential numbering in each branch (rather than sequential numbers globally as SVN does). Not sure about Mercurial. >> and .. for R-forge, e.g., which of these provide nice and >> flexible tools (as svn does) for an automatic web interface to >> inspect file histories, differences, etc. All have web interfaces. In fact FusionForge, which is the new name for G-Forge, apparently supports Git, Bzr and Hg http://fusionforge.org/ https://alioth.debian.org/scm/?group_id=30261 http://wiki.debian.org/Alioth/Hg Other examples of web interfaces can be seen on the hosting services GitHub.com e.g. http://github.com/hadley/ggplot2 Canonical's launchpad.net (bzr) e.g. https://launchpad.net/igraph >> >> Regards, >> Martin ( maintainer of svn.r-project.org ) >> >> > Regards >> > -Felix >> >> > On 26 May 2010 10:29, Felix Andrews wrote: >> >> Hi, >> >> >> >> Just wondering whether anyone had thought about moving the R sources >> >> to a "distributed" version control system such as Bazaar, Git or >> >> Mercurial. These new generation systems make it easier to work on >> >> feature branches, allow working offline, are very fast, etc. >> >> >> >> Some projects that have moved to Git are >> >> Linux Kernel >> >> Perl >> >> Ruby on Rails >> >> ... >> >> http://en.wikipedia.org/wiki/Git_(software) >> >> >> >> Some projects that have moved to Bazaar (bzr) are >> >> Ubuntu >> >> MySQL >> >> Inkscape >> >> ... >> >> http://en.wikipedia.org/wiki/Bazaar_(software) >> >> >> >> Some projects that have moved to Mercurial (hg) are >> >> Mozilla >> >> Octave >> >> Python >> >> ... >> >> http://en.wikipedia.org/wiki/Mercurial_(software) >> >> >> >> Joel Spolky's take on it: >> >> http://www.joelonsoftware.com/items/2010/03/17.html >> >> >> >> Regards >> >> -Felix > -- Felix Andrews / 安福立 Postdoctoral Fellow Integrated Catchment Assessment and Management (iCAM) Centre Fenner School of Environment and Society [Bldg 48a] The Australian National University Canberra ACT 0200 Australia M: +61 410 400 963 T: + 61 2 6125 4670 E: felix.andr...@anu.edu.au CRICOS Provider No. 00120C -- http://www.neurofractal.org/felix/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVN vs DVCS
On May 26, 2010, at 10:01 AM, Felix Andrews wrote: > I'm not necessarily advocating a migration; probably an administrative > nightmare, and everyone involved would be forced to learn new stuff... > I was just enthusing because I recently started using a DVCS for the > first time. > > > On 26 May 2010 21:16, Gabor Grothendieck wrote: >> Note that one can also use any of the dvcs systems without actually >> moving from svn by using the dvcs (or associated extension/addon) as >> an svn client or by using it on an svn checkout. > > Yes, that's a very good point (although in my experience it takes a > very long time to do the initial download of the SVN repository). I'm > not an expert on these systems, but I imagine the main downside (other > than speed) of having SVN upstream is that you have to keep the > history linear, That (non-linear history) is IMHO the biggest drawback of DVCS because that means there is no way to link a particular build to the source status and you cannot use globally valid build numbers. > and so e.g can't collaborate on feature branches this way. But feature branches are as easily (IMHO even more easily since you can closely monitor what others are contributing) worked on with SVN (routinely used with R) so I'm not sure what DVCS would buy you. AFAICS the only benefit of DVCS is that if you are on a remote island without any internet connection you can accumulate multiple commits before merging them back. I can't say that I desperately need that functionality ;). Cheers, Simon >> >> On Wed, May 26, 2010 at 5:44 AM, Martin Maechler >> wrote: Felix Andrews on Wed, 26 May 2010 11:20:12 +1000 writes: >>> >>>> On second thoughts it is really none of my business how the R sources >>>> are managed. >>>> But I would encourage package developers and/or r-forge maintainers to >>>> consider these systems. >>> >>> Thank you, Felix, for the compilation of these alternatives. >>> >>> One very relevant piece of information that you've not added, >>> is, how easily one could *move* from svn to such a system >>> (including the full history of every file with revision numbers, >>> log messages, etc), > > Indeed... here is the basic process for migrating to Git > http://www.jonmaddox.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/ > This will keep the branches, tags, full history, with SVN revision > numbers added to the log messages (if you leave off the --no-metadata > argument). However, the actual commit ids you would use in git log / > git diff / etc will not be the same as the old SVN ids. In fact git > uses hash strings rather than numbers, and bazaar uses sequential > numbering in each branch (rather than sequential numbers globally as > SVN does). Not sure about Mercurial. > >>> and .. for R-forge, e.g., which of these provide nice and >>> flexible tools (as svn does) for an automatic web interface to >>> inspect file histories, differences, etc. > > All have web interfaces. In fact FusionForge, which is the new name > for G-Forge, apparently supports Git, Bzr and Hg > http://fusionforge.org/ > https://alioth.debian.org/scm/?group_id=30261 > http://wiki.debian.org/Alioth/Hg > > Other examples of web interfaces can be seen on the hosting services > GitHub.com e.g. http://github.com/hadley/ggplot2 > Canonical's launchpad.net (bzr) e.g. https://launchpad.net/igraph > > >>> >>> Regards, >>> Martin ( maintainer of svn.r-project.org ) >>> >>>> Regards >>>> -Felix >>> >>>> On 26 May 2010 10:29, Felix Andrews wrote: >>>>> Hi, >>>>> >>>>> Just wondering whether anyone had thought about moving the R sources >>>>> to a "distributed" version control system such as Bazaar, Git or >>>>> Mercurial. These new generation systems make it easier to work on >>>>> feature branches, allow working offline, are very fast, etc. >>>>> >>>>> Some projects that have moved to Git are >>>>> Linux Kernel >>>>> Perl >>>>> Ruby on Rails >>>>> ... >>>>> http://en.wikipedia.org/wiki/Git_(software) >>>>> >>>>> Some projects that have moved to Bazaar (bzr) are >>>>> Ubuntu >>>>> MySQL >>>>> Inkscape >>>>> ... >>>>> http://en.wikipedia.org/wiki/Bazaar_(software) >>>>> >>>>> Some projects that have moved to Mercurial (hg) are >>>>> Mozilla >>>>> Octave >>>>> Python >>>>> ... >>>>> http://en.wikipedia.org/wiki/Mercurial_(software) >>>>> >>>>> Joel Spolky's take on it: >>>>> http://www.joelonsoftware.com/items/2010/03/17.html >>>>> >>>>> Regards >>>>> -Felix >> > > > > -- > Felix Andrews / 安福立 > Postdoctoral Fellow > Integrated Catchment Assessment and Management (iCAM) Centre > Fenner School of Environment and Society [Bldg 48a] > The Australian National University > Canberra ACT 0200 Australia > M: +61 410 400 963 > T: + 61 2 6125 4670 > E: felix.andr...@anu.edu.au > CRICOS Pro
Re: [Rd] SVN vs DVCS
>> Yes, that's a very good point (although in my experience it takes a >> very long time to do the initial download of the SVN repository). I'm >> not an expert on these systems, but I imagine the main downside (other >> than speed) of having SVN upstream is that you have to keep the >> history linear, > > That (non-linear history) is IMHO the biggest drawback of DVCS because that > means there is no way to link a particular build to the source status and you > cannot use globally valid build numbers. Git (and I'm sure the others) provides a globally unique id for each revision. Isn't that sufficient? > But feature branches are as easily (IMHO even more easily since you can > closely monitor what others are contributing) worked on with SVN (routinely > used with R) so I'm not sure what DVCS would buy you. Feature branches are _much_ easier with git - to the point where some people suggest using a separate feature branch for every feature you develop. > AFAICS the only benefit of DVCS is that if you are on a remote island without > any internet connection you can accumulate multiple commits before merging > them back. I can't say that I desperately need that functionality ;). You have never worked on an airplane or other location without internet access? You must have lived a very privileged life ;) Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVN vs DVCS
> and .. for R-forge, e.g., which of these provide nice and > flexible tools (as svn does) for an automatic web interface to > inspect file histories, differences, etc. Every svn alternative provides tools that are as good as or better than R-forge, with the exception of package building. It's a real shame that this unique component of R-forge is so closely connected to the tools that many other sites provide. See http://github.com/hadley/plyr for an example of the development experience that other sites provide. Note the absence of broken images and broken https. Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVN vs DVCS
2010/5/26 Hadley Wickham : >>> Yes, that's a very good point (although in my experience it takes a >>> very long time to do the initial download of the SVN repository). I'm >>> not an expert on these systems, but I imagine the main downside (other >>> than speed) of having SVN upstream is that you have to keep the >>> history linear, >> >> That (non-linear history) is IMHO the biggest drawback of DVCS because that >> means there is no way to link a particular build to the source status and >> you cannot use globally valid build numbers. > > Git (and I'm sure the others) provides a globally unique id for each > revision. Isn't that sufficient? > >> But feature branches are as easily (IMHO even more easily since you can >> closely monitor what others are contributing) worked on with SVN (routinely >> used with R) so I'm not sure what DVCS would buy you. > > Feature branches are _much_ easier with git - to the point where some > people suggest using a separate feature branch for every feature you > develop. > >> AFAICS the only benefit of DVCS is that if you are on a remote island >> without any internet connection you can accumulate multiple commits before >> merging them back. I can't say that I desperately need that functionality ;). > > You have never worked on an airplane or other location without > internet access? You must have lived a very privileged life ;) Some people just have decent web access only at work, and if you work on your R project like at home or on the train, you're already having some difficulties. But please, not the airplane argument! (just joking...). Moreover, 'local' commits are way faster than network-based commits. I can testify: 1microsecond vs 1second delay (or more, depending on how crappy is your net access) *is* a big difference. On your local machine, you end up committing much more often, with smaller and self-contained commits, generally producing a cleaner history. fabio. > > Hadley > > > -- > Assistant Professor / Dobelman Family Junior Chair > Department of Statistics / Rice University > http://had.co.nz/ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Antonio Fabio Di Narzo, PhD. Swiss Institute for Bioinformatics - Bioinformatics Core Facility Office 2029, Génopode, Quartier Sorge CH-1015 Lausanne, Switzerland Tel: +41 21 692 4087 Fax: +41 21 692 4065 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVN vs DVCS
On May 26, 2010, at 11:35 AM, Hadley Wickham wrote: >>> Yes, that's a very good point (although in my experience it takes a >>> very long time to do the initial download of the SVN repository). I'm >>> not an expert on these systems, but I imagine the main downside (other >>> than speed) of having SVN upstream is that you have to keep the >>> history linear, >> >> That (non-linear history) is IMHO the biggest drawback of DVCS because that >> means there is no way to link a particular build to the source status and >> you cannot use globally valid build numbers. > > Git (and I'm sure the others) provides a globally unique id for each > revision. Isn't that sufficient? > No in that you cannot follow revisions. What you get are those horrible UUIDs that you can't seriously use other that in some autogenerated form (that's one of the main reasons I abandoned GIt after giving it a try). >> But feature branches are as easily (IMHO even more easily since you can >> closely monitor what others are contributing) worked on with SVN (routinely >> used with R) so I'm not sure what DVCS would buy you. > > Feature branches are _much_ easier with git - to the point where some > people suggest using a separate feature branch for every feature you > develop. > Ok, what's different? It's trivial to create branches in SVN and trivial to merge - how is it easier in git? That may be the part I don't understand.. >> AFAICS the only benefit of DVCS is that if you are on a remote island >> without any internet connection you can accumulate multiple commits before >> merging them back. I can't say that I desperately need that functionality ;). > > You have never worked on an airplane or other location without internet > access? You must have lived a very privileged life ;) > Oh, you don't have internet in your airplane? ;) But seriously, yes, I have hacked stuff on airplanes but in general I'm able to get an access soon enough to have reasonable commit granularity. But yes, I do agree that it can be useful at very limited number of times (maybe once or twice so far for me), but that doesn't convince me to give up revisions and central conflict resolution which I use daily. [Note: this is my personal preference] Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVN vs DVCS
On Wed, May 26, 2010 at 11:38 AM, Hadley Wickham wrote: > It's a real > shame that this unique component of R-forge is so closely connected to > the tools that many other sites provide. R-Forge does have the capability of mirroring an external subversion repository according to section 4.2 of the R-Forge manual: http://r-forge.r-project.org/R-Forge_Manual.pdf __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVN vs DVCS
On May 26, 2010, at 12:26 PM, Antonio, Fabio Di Narzo wrote: > 2010/5/26 Hadley Wickham : Yes, that's a very good point (although in my experience it takes a very long time to do the initial download of the SVN repository). I'm not an expert on these systems, but I imagine the main downside (other than speed) of having SVN upstream is that you have to keep the history linear, >>> >>> That (non-linear history) is IMHO the biggest drawback of DVCS because that >>> means there is no way to link a particular build to the source status and >>> you cannot use globally valid build numbers. >> >> Git (and I'm sure the others) provides a globally unique id for each >> revision. Isn't that sufficient? >> >>> But feature branches are as easily (IMHO even more easily since you can >>> closely monitor what others are contributing) worked on with SVN (routinely >>> used with R) so I'm not sure what DVCS would buy you. >> >> Feature branches are _much_ easier with git - to the point where some >> people suggest using a separate feature branch for every feature you >> develop. >> >>> AFAICS the only benefit of DVCS is that if you are on a remote island >>> without any internet connection you can accumulate multiple commits before >>> merging them back. I can't say that I desperately need that functionality >>> ;). >> >> You have never worked on an airplane or other location without >> internet access? You must have lived a very privileged life ;) > > Some people just have decent web access only at work, and if you work > on your R project like at home or on the train, you're already having > some difficulties. But please, not the airplane argument! (just > joking...). > > Moreover, 'local' commits are way faster than network-based commits. I > can testify: 1microsecond vs 1second delay (or more, depending on how > crappy is your net access) *is* a big difference. On your local > machine, you end up committing much more often, with smaller and > self-contained commits, generally producing a cleaner history. > I disagree - I don't find commit time having any impact on what I commit. It's always a logical chunk (which is why SVN was such a great step forward from CVS). My RForge does check on commit so I don't even bother waiting for the commit to finish (waiting is just useful if I want the check result - the actual commit is pretty much instantaneous). However, with SVN you'll know immediately if someone else was working on the same issue in the meantime - with DVCS you won't (this happens in R more often that you would think). [Note: again, this is rather about personal preferences I suspect] Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVN vs DVCS
On 5/26/10 4:16 AM, Gabor Grothendieck wrote: Note that one can also use any of the dvcs systems without actually moving from svn by using the dvcs (or associated extension/addon) as an svn client or by using it on an svn checkout. FWIW, I have been using git for several years now as my vsc of choice and use it for all svn-backed projects (R included) via git-svn. Some of the things I like: - Being able to organize changes in local commits that can be revised, reordered, rebased prior to publishing. Once I got in the habit of working this way, I simply can't imagine going back. - Having quick access to full repository history without network access/delay. Features for searching change history are more powerful (or easier for me to use) and I have found that useful as well. - This may not be true any longer with more recent svn servers/clients, but aside form the initial repo clone, working via git-svn was noticeably faster than straight svn client (!) -- I think related to how the tools organize the working copy and how many fstat calls they make. - I find the log reviewing functionality much better suited to reviewing changes. + seth -- Seth Falcon | @sfalcon | http://userprimary.net/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 2.10 and help
Hi all, I've been developing a little project for the past few months on R2.9. The project utilises RServe to access R over at tcp/ip connection. One feature of the project is to take R-Help and display it to the user through my own UI. In 2.9 this worked well as all the html help was pre-generated - I could ask R to find the help (e.g. help(plot) would return the rd file), and then I could look up the .html file from that. In R 2.10 things changed dramatically for help, and now html help is generated when requested from the rd files. I've tried various ways to access the help as HTML since then, but I've had no luck. I was wondering if anyone would be able to suggest an approach where I could run 'help(plot)', and then take the resulting .rd file and generate the necessary html help from it. Thanks, -- Jamie Love __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVN vs DVCS
2010/5/26 Simon Urbanek : > > On May 26, 2010, at 12:26 PM, Antonio, Fabio Di Narzo wrote: > >> 2010/5/26 Hadley Wickham : > Yes, that's a very good point (although in my experience it takes a > very long time to do the initial download of the SVN repository). I'm > not an expert on these systems, but I imagine the main downside (other > than speed) of having SVN upstream is that you have to keep the > history linear, That (non-linear history) is IMHO the biggest drawback of DVCS because that means there is no way to link a particular build to the source status and you cannot use globally valid build numbers. >>> >>> Git (and I'm sure the others) provides a globally unique id for each >>> revision. Isn't that sufficient? >>> But feature branches are as easily (IMHO even more easily since you can closely monitor what others are contributing) worked on with SVN (routinely used with R) so I'm not sure what DVCS would buy you. >>> >>> Feature branches are _much_ easier with git - to the point where some >>> people suggest using a separate feature branch for every feature you >>> develop. >>> AFAICS the only benefit of DVCS is that if you are on a remote island without any internet connection you can accumulate multiple commits before merging them back. I can't say that I desperately need that functionality ;). >>> >>> You have never worked on an airplane or other location without >>> internet access? You must have lived a very privileged life ;) >> >> Some people just have decent web access only at work, and if you work >> on your R project like at home or on the train, you're already having >> some difficulties. But please, not the airplane argument! (just >> joking...). >> >> Moreover, 'local' commits are way faster than network-based commits. I >> can testify: 1microsecond vs 1second delay (or more, depending on how >> crappy is your net access) *is* a big difference. On your local >> machine, you end up committing much more often, with smaller and >> self-contained commits, generally producing a cleaner history. >> > > I disagree - I don't find commit time having any impact on what I commit. > It's always a logical chunk (which is why SVN was such a great step forward > from CVS). My RForge does check on commit so I don't even bother waiting for > the commit to finish (waiting is just useful if I want the check result - the > actual commit is pretty much instantaneous). > However, with SVN you'll know immediately if someone else was working on the > same issue in the meantime - with DVCS you won't (this happens in R more > often that you would think). You'll know immediately as long as you're connected, and that holds for DVCS too. Beside, people working simultaneously on the same files and needing svn to tell them of that? And that happening often? I would hope on better human interaction and work division, rather than svn conflicts checks. But... > [Note: again, this is rather about personal preferences I suspect] indeed. cheers, fabio. > > Cheers, > Simon > > -- Antonio Fabio Di Narzo, PhD. Swiss Institute for Bioinformatics - Bioinformatics Core Facility Office 2029, Génopode, Quartier Sorge CH-1015 Lausanne, Switzerland Tel: +41 21 692 4087 Fax: +41 21 692 4065 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.10 and help
On May 26, 2010, at 4:51 PM, Jamie Love wrote: > Hi all, > > I've been developing a little project for the past few months on R2.9. > The project utilises RServe to access R over at tcp/ip connection. > > One feature of the project is to take R-Help and display it to the > user through my own UI. In 2.9 this worked well as all the html help > was pre-generated - I could ask R to find the help (e.g. help(plot) > would return the rd file), and then I could look up the .html file > from that. > > In R 2.10 things changed dramatically for help, and now html help is > generated when requested from the rd files. > > I've tried various ways to access the help as HTML since then, but > I've had no luck. I was wondering if anyone would be able to suggest > an approach where I could run 'help(plot)', and then take the > resulting .rd file and generate the necessary html help from it. > It's much more simple since 2.10 as you can simply use the URL (same URL as the help system uses). For examples see JGR or the Mac GUI. Or you can do the same thing that the Rhttpd server does actually generating the html - see tools:::httpd Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVN vs DVCS
Antonio, Fabio Di Narzo wrote: > Beside, people working simultaneously on the same files and needing > svn to tell them of that? And that happening often? I would hope on > better human interaction and work division, rather than svn conflicts > checks. But... >> [Note: again, this is rather about personal preferences I suspect] > indeed. It actually happens quite often. Sometimes because two people in, say, Canada and Oxford fix the same bug report (usually in nearly the same way), but more typically because ALL our changes are recorded in the same NEWS file. Besides, SVN conflict are almost always trivial to resolve: Either a matter of selecting one of two changes or keeping both. -- Peter Dalgaard Center for Statistics, Copenhagen Business School Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVN vs DVCS
On Wednesday, May 26, 2010, Peter Dalgaard wrote: > Antonio, Fabio Di Narzo wrote: > >> Beside, people working simultaneously on the same files and needing >> svn to tell them of that? And that happening often? I would hope on >> better human interaction and work division, rather than svn conflicts >> checks. But... >>> [Note: again, this is rather about personal preferences I suspect] >> indeed. > > It actually happens quite often. Sometimes because two people in, say, > Canada and Oxford fix the same bug report (usually in nearly the same > way), but more typically because ALL our changes are recorded in the > same NEWS file. > > Besides, SVN conflict are almost always trivial to resolve: Either a > matter of selecting one of two changes or keeping both. And that's no more difficult in git or any other dvcs. Hadley > -- > Peter Dalgaard > Center for Statistics, Copenhagen Business School > Phone: (+45)38153501 > Email: pd@cbs.dk Priv: pda...@gmail.com > > __ > r-de...@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.10 and help
>> I've tried various ways to access the help as HTML since then, but >> I've had no luck. I was wondering if anyone would be able to suggest >> an approach where I could run 'help(plot)', and then take the >> resulting .rd file and generate the necessary html help from it. >> > > It's much more simple since 2.10 as you can simply use the URL (same URL as > the help system uses). For examples see JGR or the Mac GUI. Or you can do the > same thing that the Rhttpd server does actually generating the html - see > tools:::httpd Another approach along the same lines is the in progress helpr package: http://github.com/hadley/helpr Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
