[Rd] SVN vs DVCS

[Antonio, Fabio Di Narzo]

2010/5/26 Simon Urbanek <simon.urbanek at r-project.org>:
>
> On May 26, 2010, at 12:26 PM, Antonio, Fabio Di Narzo wrote:
>
>> 2010/5/26 Hadley Wickham <hadley at rice.edu>:
>>>>> 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