SVN vs DVCS

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

SVN vs DVCS

Felix Andrews
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: [hidden email]
CRICOS Provider No. 00120C
--
http://www.neurofractal.org/felix/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN vs DVCS

Felix Andrews
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 <[hidden email]> 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: [hidden email]
> 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: [hidden email]
CRICOS Provider No. 00120C
--
http://www.neurofractal.org/felix/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN vs DVCS

Martin Maechler
>>>>> Felix Andrews <[hidden email]>
>>>>>     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 <[hidden email]> 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: [hidden email]
    >> 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: [hidden email]
    > CRICOS Provider No. 00120C
    > --
    > http://www.neurofractal.org/felix/

    > ______________________________________________
    > [hidden email] mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN vs DVCS

Gabor Grothendieck
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
<[hidden email]> wrote:

>>>>>> Felix Andrews <[hidden email]>
>>>>>>     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 <[hidden email]> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN vs DVCS

Felix Andrews
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 <[hidden email]> 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
> <[hidden email]> wrote:
>>>>>>> Felix Andrews <[hidden email]>
>>>>>>>     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 <[hidden email]> 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: [hidden email]
CRICOS Provider No. 00120C
--
http://www.neurofractal.org/felix/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN vs DVCS

Simon Urbanek

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 <[hidden email]> 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
>> <[hidden email]> wrote:
>>>>>>>> Felix Andrews <[hidden email]>
>>>>>>>>     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 <[hidden email]> 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: [hidden email]
> CRICOS Provider No. 00120C
> --
> http://www.neurofractal.org/felix/
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN vs DVCS

Hadley Wickham-2
>> 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/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN vs DVCS

Hadley Wickham-2
In reply to this post by Martin Maechler
> 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/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN vs DVCS

Antonio, Fabio Di Narzo
In reply to this post by Hadley Wickham-2
2010/5/26 Hadley Wickham <[hidden email]>:

>>> 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/
>
> ______________________________________________
> [hidden email] 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN vs DVCS

Simon Urbanek
In reply to this post by Hadley Wickham-2

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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN vs DVCS

Simon Urbanek
In reply to this post by Antonio, Fabio Di Narzo

On May 26, 2010, at 12:26 PM, Antonio, Fabio Di Narzo wrote:

> 2010/5/26 Hadley Wickham <[hidden email]>:
>>>> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN vs DVCS

Gabor Grothendieck
In reply to this post by Hadley Wickham-2
On Wed, May 26, 2010 at 11:38 AM, Hadley Wickham <[hidden email]> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN vs DVCS

Seth Falcon-3
In reply to this post by Gabor Grothendieck
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/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN vs DVCS

Antonio, Fabio Di Narzo
In reply to this post by Simon Urbanek
2010/5/26 Simon Urbanek <[hidden email]>:

>
> On May 26, 2010, at 12:26 PM, Antonio, Fabio Di Narzo wrote:
>
>> 2010/5/26 Hadley Wickham <[hidden email]>:
>>>>> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN vs DVCS

Peter Dalgaard-2
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: [hidden email]  Priv: [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN vs DVCS

Hadley Wickham-2
On Wednesday, May 26, 2010, Peter Dalgaard <[hidden email]> 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: [hidden email]  Priv: [hidden email]
>
> ______________________________________________
> [hidden email] 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/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN vs DVCS

Therneau, Terry M., Ph.D.
In reply to this post by Felix Andrews
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN vs DVCS

Sveinung Kvilhaugsvik
> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: SVN vs DVCS

Roger Peng-2
In reply to this post by Seth Falcon-3
I think the main advantage of a DVCS is that it allows many many
people to make changes to a project and to integrate those changes in
a non-insane way. Given that R as a very restricted list of people who
actually make changes to the source, it doesn't seem that something
like git or Hg would provide a major advantage. If the people on that
list are happy with SVN then there's not much else to say. However, if
it were thought that maybe we want more people submitting
patches/making changes, then perhaps it might make more sense to move
to a DVCS.

I use git for everything mainly because it's *fast* and it has much
better tools for viewing changes/patches and revision history. For
example, 'git bisect' has allowed me track down bugs that would have
been very painful for me because I'm not intimately familiar with the
entire R source code.

-roger

On Wed, May 26, 2010 at 1:14 PM, Seth Falcon <[hidden email]> wrote:

> 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/
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



--
Roger D. Peng  |  http://www.biostat.jhsph.edu/~rpeng/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel