I’d be surprised if it’s as large as DevDiv – it’s not the Framework that is huge, it’s the largest product (in code size) that we make; VS. ;)
I suspect a GB wouldn’t be bad, I easily pull down over 10 GB in my enlistments from TFS, so assumingly a DVCS could easily handle that, only with faster commits and history. However, if you want the integration – TFS is definitely the way to go (however, I am biased ☺). From: [email protected] [mailto:[email protected]] On Behalf Of Joseph Cooney Sent: Friday, November 05, 2010 8:30 PM To: ozDotNet Cc: ozDotNet Subject: Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it? There is a mercurial vide from 2006 where they say some folks have gb-sized source trees. Mono use Git - which would be roughly the same size as a devdiv branch (an assumption based on the fact that they deliver equivalent functionality using the same language, unless you folk store VMs or something else big in your source tree that they don't). Linux kernel uses git, but they are well under a gb, as is Mozilla with hg. On 06/11/2010, at 4:32 AM, David Kean <[email protected]<mailto:[email protected]>> wrote: How big are the databases that you are using? I’d imagine that there would be huge savings in using a DVCS for small self-contained repositories, however, there would be a given size where using one would no longer be an advantage. For example, I can’t imagine a DVCS working at Microsoft; a full enlistment in one branch in DevDiv is around 300 GB (times that by 100s of branches) – having everyone pull that down and all the history along with it, would not be fun. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Mark Ryall Sent: Friday, November 05, 2010 11:19 AM To: ozDotNet Subject: Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it? I'm using svn again now after using git and hg for a few years (tfs was in there too - i don't want to talk about that). I always liked svn and found it adequate but don't anymore. There's nothing a DVCS provides that you can't live without - just as 64Kb of RAM was once perfectly adequate. There are just a whole lot of things with DVCS that suddenly become easier or possible. While you might not have considered these things earlier (because you couldn't), you really miss them when you can't. They are insanely fast - especially git. You will notice how fast they are every time you need to do a commit. Insanely fast encourages more frequent commits. The fact that after a clone, you end up with the entire history of a project locally (including every branch) in far less time than svn would take to check out a single code line (due to all the thousands of tiny control files it needs to create in every directory) is the winner for me. Hosting is free or really cheap (bitbucket/github/launchpad). For an open source project, fork/send pull request is a much lower barrier to entry for collaboration than checkout/email patch file. If you accept a pull request, that person's commit becomes part of your codebase as them without you needing to provide direct commit access (as opposed to their changes being committed from a patch by you). I prefer to avoid branching where possible but they make branching effortlessly easy. Merging with git/hg is trivial and is properly tracked unlike with svn. Merging is always awful but git in particular seems to have some preternatural ability to help you get it right. DVCS won't make you taller, more muscular or attractive though (i've tried - it really doesn't work) so use your best judgement. On Wednesday, 3 November 2010 at 6:43 PM, silky wrote: On Thu, Nov 4, 2010 at 12:37 PM, Joseph Cooney <[email protected]<mailto:[email protected]>> wrote: argumentative? silky? GTFO! :) Most of my experience with DVCS has been with mercurial (hg) which I've used for about the last 2 years for my personal stuff. Before that I used SVN. I think the difference (from my point of view) is that hg works well in a super-set of configurations to TFS/SVN. If you were a solo developer with TFS installed locally then hg probably wouldn't be that much better (it certainly handles branching, merging and backing up more cleanly than TFS/SVN). But most people don't work that way - the server is remote. If you want to look at the 'history' for a file or do a diff it's a network operation. Checking out is a network operation (at least for TFS it is...not sur e about SVN). In the case of TFS 2008 when the server was off-line work ground to a halt. With hg sometimes there _is_ no central server. I've had good experiences collaborating with other devs using hg with no central server set up, just sending patches back and forth for synchronization. You can set up your development processes such that your DVCS is fairly centralized (like things would be with TFS/SVN) - devs commit and push/pull often. Then you just get the perf wins of local disk I/O vs. network I/O and better merging capabilities. Yeah, this is what I thought. And I can't help but feel this is totally overrated. I mean, I don't know a single person who would say using SVN is slow. It's never slowed me down at all (perhaps I'm just slow in general?). Checkout takes a while, sure, but you don't do that every day. Infact, you normally only do it a few times, perhaps when creating a branch or something. O kay, so you are telling me that perhaps git/hg is better because you automatically get your 'own' repo and you need to specifically 'push' it to the core; thus kind of creating a versioned development pattern automatically. Alright. I can accept that as useful. High-level summary (from my POV) - DVCS well in a super-set of configurations to old skool SVN/TFS/CVS Joseph -- w: http://jcooney.net t: @josephcooney -- silky http://dnoondt.wordpress.com/ "Every morning when I wake up, I experience an exquisite joy — the joy of being this signature."
