2010/5/26 Simon Urbanek <simon.urba...@r-project.org>: > > On May 26, 2010, at 12:26 PM, Antonio, Fabio Di Narzo wrote: > >> 2010/5/26 Hadley Wickham <had...@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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
