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/
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. 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/ >-- 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/
One small technical note: Simon said> 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.In mercurial (Hg) a particular snapshot can be labeled with a tag, and then referred to by that name in the future. This problem and solution is discussed in a tutorial on Mecurial (http://hginit.com/, section on "repository architecture"), precisely for matching the archive state to a software release. I can't speak to any other DVCS package. Terry Therneau
> In mercurial (Hg) a particular snapshot can be labeled with a tag, and > then referred to by that name in the future.Bazaar can tag revisions as well: http://wiki.bazaar.canonical.com/Tag Git too: http://www.kernel.org/pub/software/scm/git/docs/git-tag.html Sincerely Sveinung Kvilhaugsvik