Yeah, tfs integration is very good. There is a dvcs that has integrated bug, 
work item tracking and wiki (called fossil) from the makers of sqlite. I 
haven't used it, but it will be interesting to see how long tfs retains this 
advantage.

On 06/11/2010, at 6:01 PM, David Kean <[email protected]> wrote:

> 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 J).
> 
>  
> 
> 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]> 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]] 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]> 
> 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."
> 
>  

Reply via email to