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 <ggrothendieck at gmail.com> 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 <maechler at stat.math.ethz.ch> wrote:
Felix Andrews <felix at nfrac.org>
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 <felix at nfrac.org> 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.andrews at anu.edu.au CRICOS Provider No. 00120C -- http://www.neurofractal.org/felix/
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel