RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[Paul Stovell]

I wonder if that's a product of TFS architecture - generally most companies 
have one TFS server, with many team projects and project collections. There are 
licensing/admin costs associated with doing it differently.

With a DVCS you might find you end up with lots of smaller repositories - one 
for the VS core, individual repositories for different VS features, different 
repositories for branches, different repositories for System.Web.* vs. WPF vs. 
WCF, etc.


From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of David Kean
Sent: Saturday, 6 November 2010 4:32 AM
To: ozDotNet
Subject: RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] 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 
mailto:joseph.coo...@gmail.com>> 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. Inf

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[silky]

On Sun, Nov 7, 2010 at 10:23 AM, Joseph Cooney  wrote:
> 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.

You've been able to do this since forever with svn+trac, and it looks
like there is a plugin for mercurial as well:
http://trac.edgewall.org/wiki/TracMercurial


> 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."

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[Joseph Cooney]

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  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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] 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  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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] 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  
> 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 configurati

RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[David Kean]

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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] 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 
mailto:david.k...@microsoft.com>> 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: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com] 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 
mailto:joseph.coo...@gmail.com>> 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

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[Joseph Cooney]

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  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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] 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  
> 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
> totall

RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[David Kean]

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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] 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 
mailto:joseph.coo...@gmail.com>> 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."

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[Mark Ryall]

 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 
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."

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[silky]

On Fri, Nov 5, 2010 at 12:42 PM, mike smith  wrote:
> On 5 November 2010 10:59, silky  wrote:
>> On Fri, Nov 5, 2010 at 10:54 AM, Grant Molloy  wrote:
>>> Putting the flavour of your DVCS aside for the moment...
>>>
>>> How "secure" do you feel having all your code, IP, etc, sitting on somebody
>>> elses servers ?
>>>
>>> If they shut up shop tomorrow, do you keep a local copy of everything too ??
>>> What cost per month are you paying to have it hosted *in the cloud* ?
>>> (sounds so Web 3.0 !!).
>>
>> Who is this directed to? Me? (because I've got SVN hosted at amazon?)
>>
>> I feel fine. I've got backups of all my code on two drives anyway, and
>> of course I have it all on my laptop.
>>
>> If Amazon shut up shop tomorrow, I'll lose a bit of data, but not much else.
>>
>> Any reasonable person has backups ...
>
> Backups of the code, or the rev history and all that?

Code.

I'll admit I haven't got an full svn backup going on the server at the
moment, but to be honest if I lose that I'm not going to be too
concerned.


> --
> Meski
>
> "Going to Starbucks for coffee is like going to prison for sex. Sure,
> you'll get it, but it's going to be rough" - Adam Hills

-- 
silky

http://dnoondt.wordpress.com/

"Every morning when I wake up, I experience an exquisite joy — the joy
of being this signature."

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[mike smith]

On 5 November 2010 10:59, silky  wrote:
> On Fri, Nov 5, 2010 at 10:54 AM, Grant Molloy  wrote:
>> Putting the flavour of your DVCS aside for the moment...
>>
>> How "secure" do you feel having all your code, IP, etc, sitting on somebody
>> elses servers ?
>>
>> If they shut up shop tomorrow, do you keep a local copy of everything too ??
>> What cost per month are you paying to have it hosted *in the cloud* ?
>> (sounds so Web 3.0 !!).
>
> Who is this directed to? Me? (because I've got SVN hosted at amazon?)
>
> I feel fine. I've got backups of all my code on two drives anyway, and
> of course I have it all on my laptop.
>
> If Amazon shut up shop tomorrow, I'll lose a bit of data, but not much else.
>
> Any reasonable person has backups ...

Backups of the code, or the rev history and all that?




-- 
Meski

"Going to Starbucks for coffee is like going to prison for sex. Sure,
you'll get it, but it's going to be rough" - Adam Hills

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[mike smith]

On 5 November 2010 09:55, David Connors  wrote:
> On 5 November 2010 08:37, mike smith  wrote:
>>
>> > 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 is glacially slow when your repository is not local.  There, a
>> single person has said it.  Look at minute/s to do something like a
>> diff at times.  Go off and make a coffee/s if you're doing an entire
>> update.  Have lunch if you're picking up all the code for the first
>> time.
>
> Either you have SVN set up incorrectly or the problem isn't really 'not
> local' but your Internet link.

Quite possible, but I have no way of getting either tweaked in my
corporate environment.

> All of our stuff sits in a managed DC and we actually VPN in to our core
> company network, and that is where SVN resides.
> I regularly get over a meg a second doing a checkout. I just did a checkout
> on a project I've not touched in a while and got 40.71 megabytes in 38
> seconds - as a mixture of small files and large. I'd hardly call that
> glacially slow. I'd actually call that pretty damned quick all things

Update ...
1.5 min to get initial response.

7.7 MB in 4min 13 sec.
Merged 2 Added 22 updated 155



> considered.
> I just asked it for a revision graph in the documentation folder of the same
> project (at revision 542) and it only took 6 seconds.

4min

> --
> David Connors | da...@codify.com | www.codify.com
> Software Engineer
> Codify Pty Ltd
> Phone: +61 (7) 3210 6268 | Facsimile: +61 (7) 3210 6269 | Mobile: +61 417
> 189 363
> V-Card: https://www.codify.com/cards/davidconnors
> Address Info: https://www.codify.com/contact
>
>



-- 
Meski

"Going to Starbucks for coffee is like going to prison for sex. Sure,
you'll get it, but it's going to be rough" - Adam Hills

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[Grant Molloy]

Hi Silky,
Wasn't directed directly at you, but at anyone who wants to provide an
answer...

Wow... $90 a month IS expensive.. but tax deductible !!


On Fri, Nov 5, 2010 at 9:59 AM, silky  wrote:

> On Fri, Nov 5, 2010 at 10:54 AM, Grant Molloy  wrote:
> > Putting the flavour of your DVCS aside for the moment...
> >
> > How "secure" do you feel having all your code, IP, etc, sitting on
> somebody
> > elses servers ?
> >
> > If they shut up shop tomorrow, do you keep a local copy of everything too
> ??
> > What cost per month are you paying to have it hosted *in the cloud* ?
> > (sounds so Web 3.0 !!).
>
> Who is this directed to? Me? (because I've got SVN hosted at amazon?)
>
> I feel fine. I've got backups of all my code on two drives anyway, and
> of course I have it all on my laptop.
>
> If Amazon shut up shop tomorrow, I'll lose a bit of data, but not much
> else.
>
> Any reasonable person has backups ...
>
> The server I have cost ~90 per month. It's expensive.
>
>
> > Grant
>
> --
> silky
>
> http://dnoondt.wordpress.com/
>
> "Every morning when I wake up, I experience an exquisite joy — the joy
> of being this signature."
>

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[silky]

On Fri, Nov 5, 2010 at 10:54 AM, Grant Molloy  wrote:
> Putting the flavour of your DVCS aside for the moment...
>
> How "secure" do you feel having all your code, IP, etc, sitting on somebody
> elses servers ?
>
> If they shut up shop tomorrow, do you keep a local copy of everything too ??
> What cost per month are you paying to have it hosted *in the cloud* ?
> (sounds so Web 3.0 !!).

Who is this directed to? Me? (because I've got SVN hosted at amazon?)

I feel fine. I've got backups of all my code on two drives anyway, and
of course I have it all on my laptop.

If Amazon shut up shop tomorrow, I'll lose a bit of data, but not much else.

Any reasonable person has backups ...

The server I have cost ~90 per month. It's expensive.


> Grant

-- 
silky

http://dnoondt.wordpress.com/

"Every morning when I wake up, I experience an exquisite joy — the joy
of being this signature."

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[Grant Molloy]

Putting the flavour of your DVCS aside for the moment...
How "secure" do you feel having all your code, IP, etc, sitting on somebody
elses servers ?
If they shut up shop tomorrow, do you keep a local copy of everything too ??
What cost per month are you paying to have it hosted *in the cloud* ?
(sounds so Web 3.0 !!).

Grant

On Fri, Nov 5, 2010 at 9:11 AM, David Russell  wrote:

> Hi, I would just like to say I disagree with this assessment of merging in
> TFS.
>
> In TFS, you would also merge the 19 changes from Trunk into the Feature
> branch first, resolve conflicts & checkin, then merge Feature branch back
> into Trunk. This generally works well. Cherry-picking merges is a different
> story, but can also be straightforward.
>
> It is true that a merge results in a new single 'mushed' changeset in the
> target, but this doesn't mean you lose the context of the original checkins
> - In VS 2010, the History view shows the originating changesets as a tree
> (even after the source branch has been deleted), and the Branch
> Visualisation tool can help you track a changeset across multiple branches.
>
> That isn't to say TFS is without its problems. The trouble we have with TFS
> merges tends to be with deletes, renames, changes you DON'T want to merge,
> partial merges (for changesets that span multiple branch-points), forgetting
> to Get Latest of a target branch before merging, rollbacks, cherry-picking
> non-sequential changesets, and occasionally poor auto-merging. Thankfully,
> some of this has substantially improved in TFS 2010 since they changed to
> 'slot' mode when dealing with deletes, renames, and undeletes, as well as a
> proper rollback command. But these problems only occur occasionally and we
> manage to deal with them.
>
> I have not used other source control systems (other than VSS - does that
> count? ;) so maybe I am missing something in the comparison, but as someone
> who comes from a background of merging code _manually_ for many years, I
> think TFS merging is generally fine I don't think it is broken.
>
> Branch Visualization:
> http://www.edsquared.com/2010/03/17/Branching+And+Track+Changes+Visualization+In+TFS+2010+Is+Awesome.aspx
> 'Slot' mode:
> http://blogs.msdn.com/b/mitrik/archive/2009/05/28/changing-to-slot-mode-in-tfs-2010-version-control.aspx
>
>
> -Original Message-
> From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
> On Behalf Of Paul Stovell
> Sent: Thursday, 4 November 2010 6:11 PM
> To: ozDotNet
> Subject: RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?
>
> >> Broken how?
>
> Let's say you decide to implement a new feature in a TFS branch. You branch
> the trunk to FeatureX. Over the course of a week, you make 13 check-ins to
> that branch. During this time, the rest of your team made another 19 changes
> to the trunk. The feature is now stable, so you decide to merge. In TFS,
> this is done by doing a giant compare on the two directories, AND'ing them
> together, and seeing what falls out. You aren't just merging a check-ins -
> you're merging the state of two file system directories after 32 different
> check ins in a single attempt - you better get it right, because if you get
> 90% of the way in and screw it up, it will take a long time to recover.
>
> When you're done merging, you're left with  a huge pending check in that
> touches every file involved in those 13 commits. You have to come up with a
> nice paragraph that sums up the 13 changes you're mushing in, because when
> you delete the branch, you'll probably lose the history of those branched
> changes. You should also remember to associate it with all of the work
> items/bugs/stories those 13 check ins touched, since this huge check in is
> really associated with all of them.
>
> In Mercurial it works different. You'd pull the 19 changes made to the
> trunk to your local repository - they'd be replayed, one-by-one, against
> your files. You'll still do the merges (leaving alone that Mercurial does a
> much better job of merging than TFS out of the box), but since you're
> dealing with one or two commits at a time, the merges are pretty simple, and
> if you screw up, you don't have to start the whole thing again. Once you've
> merged the trunk into your branch, you'd just push everything back to trunk.
> Now all the changes are replayed against trunk, and trunk has all 32
> commits, with their history and dates exactly as you wrote them when you
> checked them in during the week. It's a much more elegant model.
>
> Paul
>
> -Original Message-
> From: ozdotnet-boun...@ozdo

RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[David Russell]

Hi, I would just like to say I disagree with this assessment of merging in TFS.

In TFS, you would also merge the 19 changes from Trunk into the Feature branch 
first, resolve conflicts & checkin, then merge Feature branch back into Trunk. 
This generally works well. Cherry-picking merges is a different story, but can 
also be straightforward.

It is true that a merge results in a new single 'mushed' changeset in the 
target, but this doesn't mean you lose the context of the original checkins - 
In VS 2010, the History view shows the originating changesets as a tree (even 
after the source branch has been deleted), and the Branch Visualisation tool 
can help you track a changeset across multiple branches.

That isn't to say TFS is without its problems. The trouble we have with TFS 
merges tends to be with deletes, renames, changes you DON'T want to merge, 
partial merges (for changesets that span multiple branch-points), forgetting to 
Get Latest of a target branch before merging, rollbacks, cherry-picking 
non-sequential changesets, and occasionally poor auto-merging. Thankfully, some 
of this has substantially improved in TFS 2010 since they changed to 'slot' 
mode when dealing with deletes, renames, and undeletes, as well as a proper 
rollback command. But these problems only occur occasionally and we manage to 
deal with them.

I have not used other source control systems (other than VSS - does that count? 
;) so maybe I am missing something in the comparison, but as someone who comes 
from a background of merging code _manually_ for many years, I think TFS 
merging is generally fine I don't think it is broken.

Branch Visualization: 
http://www.edsquared.com/2010/03/17/Branching+And+Track+Changes+Visualization+In+TFS+2010+Is+Awesome.aspx
'Slot' mode: 
http://blogs.msdn.com/b/mitrik/archive/2009/05/28/changing-to-slot-mode-in-tfs-2010-version-control.aspx


-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Paul Stovell
Sent: Thursday, 4 November 2010 6:11 PM
To: ozDotNet
Subject: RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

>> Broken how?

Let's say you decide to implement a new feature in a TFS branch. You branch the 
trunk to FeatureX. Over the course of a week, you make 13 check-ins to that 
branch. During this time, the rest of your team made another 19 changes to the 
trunk. The feature is now stable, so you decide to merge. In TFS, this is done 
by doing a giant compare on the two directories, AND'ing them together, and 
seeing what falls out. You aren't just merging a check-ins - you're merging the 
state of two file system directories after 32 different check ins in a single 
attempt - you better get it right, because if you get 90% of the way in and 
screw it up, it will take a long time to recover. 

When you're done merging, you're left with  a huge pending check in that 
touches every file involved in those 13 commits. You have to come up with a 
nice paragraph that sums up the 13 changes you're mushing in, because when you 
delete the branch, you'll probably lose the history of those branched changes. 
You should also remember to associate it with all of the work 
items/bugs/stories those 13 check ins touched, since this huge check in is 
really associated with all of them. 

In Mercurial it works different. You'd pull the 19 changes made to the trunk to 
your local repository - they'd be replayed, one-by-one, against your files. 
You'll still do the merges (leaving alone that Mercurial does a much better job 
of merging than TFS out of the box), but since you're dealing with one or two 
commits at a time, the merges are pretty simple, and if you screw up, you don't 
have to start the whole thing again. Once you've merged the trunk into your 
branch, you'd just push everything back to trunk. Now all the changes are 
replayed against trunk, and trunk has all 32 commits, with their history and 
dates exactly as you wrote them when you checked them in during the week. It's 
a much more elegant model. 

Paul

-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of silky
Sent: Thursday, 4 November 2010 4:51 PM
To: ozDotNet
Subject: Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

On Thu, Nov 4, 2010 at 5:40 PM, Paul Stovell  wrote:
> Hi Silky,
>
> I think in some ways you have to experience it - the proof is in the 
> tasting. But here are some things I like about it that work even for 
> small, local teams.
>
> 1.   How many times did you make a small change, then delete it 
> and try something else, only to realize that you didn't check in 
> during that time since it wasn't "ready" to share with the team? Since 
> most of your interaction w

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[David Connors]

On 5 November 2010 08:37, mike smith  wrote:

> > 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 is glacially slow when your repository is not local.  There, a
> single person has said it.  Look at minute/s to do something like a
> diff at times.  Go off and make a coffee/s if you're doing an entire
> update.  Have lunch if you're picking up all the code for the first
> time.
>

Either you have SVN set up incorrectly or the problem isn't really 'not
local' but your Internet link.

All of our stuff sits in a managed DC and we actually VPN in to our core
company network, and that is where SVN resides.

I regularly get over a meg a second doing a checkout. I just did a checkout
on a project I've not touched in a while and got 40.71 megabytes in 38
seconds - as a mixture of small files and large. I'd hardly call that
glacially slow. I'd actually call that pretty damned quick all things
considered.

I just asked it for a revision graph in the documentation folder of the same
project (at revision 542) and it only took 6 seconds.

-- 
*David Connors* | da...@codify.com | www.codify.com
Software Engineer
Codify Pty Ltd
Phone: +61 (7) 3210 6268 | Facsimile: +61 (7) 3210 6269 | Mobile: +61 417
189 363
V-Card: https://www.codify.com/cards/davidconnors
Address Info: https://www.codify.com/contact

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[silky]

>> 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 is glacially slow when your repository is not local.  There, a
> single person has said it.  Look at minute/s to do something like a
> diff at times.  Go off and make a coffee/s if you're doing an entire
> update.  Have lunch if you're picking up all the code for the first
> time.

Yeah, but I don't know you :)

And I'll respond with the opposite claim. It's not slow, and my SVN
repo is on an amazon server *over https*. And it's still fine. Now,
I'm not committing megs of stuff at once, but nevertheless. *That's*
not a reason to change.

However, the specific points raised previously in this thread, and the
comments from Dave have probably pushed me over the edge.


> --
> Meski
>
> "Going to Starbucks for coffee is like going to prison for sex. Sure,
> you'll get it, but it's going to be rough" - Adam Hills

-- 
silky

http://dnoondt.wordpress.com/

"Every morning when I wake up, I experience an exquisite joy — the joy
of being this signature."

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[mike smith]

On 4 November 2010 12:43, silky  wrote:
> On Thu, Nov 4, 2010 at 12:37 PM, Joseph Cooney  
> 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 sure 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 is glacially slow when your repository is not local.  There, a
single person has said it.  Look at minute/s to do something like a
diff at times.  Go off and make a coffee/s if you're doing an entire
update.  Have lunch if you're picking up all the code for the first
time.

>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.
>
> Okay, 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."
>



-- 
Meski

"Going to Starbucks for coffee is like going to prison for sex. Sure,
you'll get it, but it's going to be rough" - Adam Hills

RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[Paul Glavich]

I use TFS a *lot* in my day to day work. It is the enterprise SCM tool of
choice. I have recently made the switch to Mercurial (after some recent
investigation of Git and Mercurial) for my personal work projects.

I am not going to go into theory though. TFS merges and conflict resolutions
are a pain in an enterprise team environment and are a serious time waster.
Hg(Mercurial) and probably GIT just do it better. The offline support is
just better.

Now I wont advocate use of Mercurial in my current enterprise
(Mercurial/DVCS requires some knowledge and discipline in its current form).
Integration with work items, VS 2010 integration etc.. is just way too good
and it’s the default choice. Make no mistake tho, Mercurial (and GIT) are
better at source control management. You do need a bit of re-education
around how the workflow of should happen (ie. When do I checkin, push, pull
etc...) but in the end, this method is a good indicator of how the future of
SCM (IMHO) will shape up.

I recently investigated GIT/Mercurial after Mr. Stovell himself gave me a
good reason to do so but I was pragmatic around its usage. I was (and still
am) a subversion fan for my personal stuff but Mercurial does do it better.
As a dev, its odd to be excited about a new way of SCM. Geeky, but true.

- Glav

-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Paul Stovell
Sent: Thursday, 4 November 2010 6:11 PM
To: ozDotNet
Subject: RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

>> Broken how?

Let's say you decide to implement a new feature in a TFS branch. You branch
the trunk to FeatureX. Over the course of a week, you make 13 check-ins to
that branch. During this time, the rest of your team made another 19 changes
to the trunk. The feature is now stable, so you decide to merge. In TFS,
this is done by doing a giant compare on the two directories, AND'ing them
together, and seeing what falls out. You aren't just merging a check-ins -
you're merging the state of two file system directories after 32 different
check ins in a single attempt - you better get it right, because if you get
90% of the way in and screw it up, it will take a long time to recover. 

When you're done merging, you're left with  a huge pending check in that
touches every file involved in those 13 commits. You have to come up with a
nice paragraph that sums up the 13 changes you're mushing in, because when
you delete the branch, you'll probably lose the history of those branched
changes. You should also remember to associate it with all of the work
items/bugs/stories those 13 check ins touched, since this huge check in is
really associated with all of them. 

In Mercurial it works different. You'd pull the 19 changes made to the trunk
to your local repository - they'd be replayed, one-by-one, against your
files. You'll still do the merges (leaving alone that Mercurial does a much
better job of merging than TFS out of the box), but since you're dealing
with one or two commits at a time, the merges are pretty simple, and if you
screw up, you don't have to start the whole thing again. Once you've merged
the trunk into your branch, you'd just push everything back to trunk. Now
all the changes are replayed against trunk, and trunk has all 32 commits,
with their history and dates exactly as you wrote them when you checked them
in during the week. It's a much more elegant model. 

Paul

-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of silky
Sent: Thursday, 4 November 2010 4:51 PM
To: ozDotNet
Subject: Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

On Thu, Nov 4, 2010 at 5:40 PM, Paul Stovell 
wrote:
> Hi Silky,
>
> I think in some ways you have to experience it - the proof is in the 
> tasting. But here are some things I like about it that work even for 
> small, local teams.
>
> 1.   How many times did you make a small change, then delete it 
> and try something else, only to realize that you didn't check in 
> during that time since it wasn't "ready" to share with the team? Since 
> most of your interaction with source control is just to your hard 
> disk, you're more likely to use it. On my current project with 
> Mercurial I'm averaging a commit every 10 minutes - lots of small changes.

Never. I don't ever try the wrong thing.

Seriously though, as I said to Joseph, I agree this is a legitimate benefit,
and I like it.


> 2.   How many times have you done an SVN update/TFS "get latest", 
> tried to merge, made a mistake, and lost changes in the process? With 
> Mercurial that doesn't happen -it forces you to commit your local 
> changes first, then merge them with the server changes. If it fails, 
> you ca

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[David Burstin]

Just adding my 2c:

I used to use Subversion and loved it - it did everything I wanted it to do.
One day I had some time on my hands and decided to try Mercurial, just to
see what it was like. I have never used Subversion since. 90% of my stuff is
single developer and local (when I'm on contract I use whatever the use, so
that doesn't count). Like Paul says, it's really one of those things that
you need to try to see the difference. I feel "safer" and more in control
with Mercurial, it's easier to branch and merge and overall just feels
nicer.

It's all just airy fairy stuff - this post contains no real new information.
Probably  could have just summed it up by saying +1 to Mercurial. I haven't
used TFS.



On Thu, Nov 4, 2010 at 6:30 PM, silky  wrote:

> On Thu, Nov 4, 2010 at 6:10 PM, Paul Stovell 
> wrote:
> > > > Broken how?
>
> [...]
>
> > In Mercurial it works different. You'd pull the 19 changes made to the
> trunk to your local repository - they'd be replayed, one-by-one, against
> your
> > files. You'll still do the merges (leaving alone that Mercurial does a
> much better job of merging than TFS out of the box), but since you're
> dealing
> > with one or two commits at a time, the merges are pretty simple, and if
> you screw up, you don't have to start the whole thing again. Once you've
> > merged the trunk into your branch, you'd just push everything back to
> trunk. Now all the changes are replayed against trunk, and trunk has all 32
> > commits, with their history and dates exactly as you wrote them when you
> checked them in during the week. It's a much more elegant model.
>
> Right. (Sorry if I wasn't clear, but I haven't used TFS and was more
> interested in how you consider Subversions merge broken; I understand
> that in the system you are describing it is 'different', I don't see
> any point in calling Subversion 'broken' though).
>
>
> > Paul
>
> --
> silky
>
> http://dnoondt.wordpress.com/
>
> "Every morning when I wake up, I experience an exquisite joy — the joy
> of being this signature."
>

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[silky]

On Thu, Nov 4, 2010 at 6:10 PM, Paul Stovell  wrote:
> > > Broken how?

[...]

> In Mercurial it works different. You'd pull the 19 changes made to the trunk 
> to your local repository - they'd be replayed, one-by-one, against your
> files. You'll still do the merges (leaving alone that Mercurial does a much 
> better job of merging than TFS out of the box), but since you're dealing
> with one or two commits at a time, the merges are pretty simple, and if you 
> screw up, you don't have to start the whole thing again. Once you've
> merged the trunk into your branch, you'd just push everything back to trunk. 
> Now all the changes are replayed against trunk, and trunk has all 32
> commits, with their history and dates exactly as you wrote them when you 
> checked them in during the week. It's a much more elegant model.

Right. (Sorry if I wasn't clear, but I haven't used TFS and was more
interested in how you consider Subversions merge broken; I understand
that in the system you are describing it is 'different', I don't see
any point in calling Subversion 'broken' though).


> Paul

-- 
silky

http://dnoondt.wordpress.com/

"Every morning when I wake up, I experience an exquisite joy — the joy
of being this signature."

RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[Paul Stovell]

>> Broken how?

Let's say you decide to implement a new feature in a TFS branch. You branch the 
trunk to FeatureX. Over the course of a week, you make 13 check-ins to that 
branch. During this time, the rest of your team made another 19 changes to the 
trunk. The feature is now stable, so you decide to merge. In TFS, this is done 
by doing a giant compare on the two directories, AND'ing them together, and 
seeing what falls out. You aren't just merging a check-ins - you're merging the 
state of two file system directories after 32 different check ins in a single 
attempt - you better get it right, because if you get 90% of the way in and 
screw it up, it will take a long time to recover. 

When you're done merging, you're left with  a huge pending check in that 
touches every file involved in those 13 commits. You have to come up with a 
nice paragraph that sums up the 13 changes you're mushing in, because when you 
delete the branch, you'll probably lose the history of those branched changes. 
You should also remember to associate it with all of the work 
items/bugs/stories those 13 check ins touched, since this huge check in is 
really associated with all of them. 

In Mercurial it works different. You'd pull the 19 changes made to the trunk to 
your local repository - they'd be replayed, one-by-one, against your files. 
You'll still do the merges (leaving alone that Mercurial does a much better job 
of merging than TFS out of the box), but since you're dealing with one or two 
commits at a time, the merges are pretty simple, and if you screw up, you don't 
have to start the whole thing again. Once you've merged the trunk into your 
branch, you'd just push everything back to trunk. Now all the changes are 
replayed against trunk, and trunk has all 32 commits, with their history and 
dates exactly as you wrote them when you checked them in during the week. It's 
a much more elegant model. 

Paul

-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of silky
Sent: Thursday, 4 November 2010 4:51 PM
To: ozDotNet
Subject: Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

On Thu, Nov 4, 2010 at 5:40 PM, Paul Stovell  wrote:
> Hi Silky,
>
> I think in some ways you have to experience it - the proof is in the 
> tasting. But here are some things I like about it that work even for 
> small, local teams.
>
> 1.   How many times did you make a small change, then delete it 
> and try something else, only to realize that you didn't check in 
> during that time since it wasn't "ready" to share with the team? Since 
> most of your interaction with source control is just to your hard 
> disk, you're more likely to use it. On my current project with 
> Mercurial I'm averaging a commit every 10 minutes - lots of small changes.

Never. I don't ever try the wrong thing.

Seriously though, as I said to Joseph, I agree this is a legitimate benefit, 
and I like it.


> 2.   How many times have you done an SVN update/TFS "get latest", 
> tried to merge, made a mistake, and lost changes in the process? With 
> Mercurial that doesn't happen -it forces you to commit your local 
> changes first, then merge them with the server changes. If it fails, 
> you can roll it back and try again until you're successful - you never lose 
> changes.

This I've legitimately never done. Merging with SVN is pretty nice, at least I 
think so. You just go around resolving conflicts. Not so tough. Don't disagree 
that it could be better, but I don't think there is an issue here particularly.


> 3.   Merging in DVC's works fantastically. By comparison the 
> merging approaches of TFS and Subversion are broken. To even use a 
> DVCS you're using branching and merging, since the server and your 
> local machine are entirely different repositories. In TFS and SVN, 
> branching and merging is a scary concept only used in the most dire of 
> circumstances.

Broken how?


> Those advantages apply in the most connected corporate environment - 
> when I'm forced to use TFS I wish it had better support for these three 
> features.
> Prior to using Mercurial I just accepted that the way SVN made me work 
> was fine, and the occasional loss of code or busted merge was a fact of life.
> Now I find it frustrating to work with TFS/Subversion and sometimes 
> wonder if a folder full of "copy of .".zip files would be more 
> effective J
>
> There are other advantages to do specifically with open source 
> projects - for instance, instead of sending a patch, people can put 
> their repository online to share with others, and you can cherry pick 
> the changes you want from them. The patchi

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[silky]

On Thu, Nov 4, 2010 at 5:40 PM, Paul Stovell  wrote:
> Hi Silky,
>
> I think in some ways you have to experience it - the proof is in the
> tasting. But here are some things I like about it that work even for small,
> local teams.
>
> 1.   How many times did you make a small change, then delete it and try
> something else, only to realize that you didn’t check in during that time
> since it wasn’t “ready” to share with the team? Since most of your
> interaction with source control is just to your hard disk, you’re more
> likely to use it. On my current project with Mercurial I’m averaging a
> commit every 10 minutes – lots of small changes.

Never. I don't ever try the wrong thing.

Seriously though, as I said to Joseph, I agree this is a legitimate
benefit, and I like it.


> 2.   How many times have you done an SVN update/TFS “get latest”, tried
> to merge, made a mistake, and lost changes in the process? With Mercurial
> that doesn’t happen –it forces you to commit your local changes first, then
> merge them with the server changes. If it fails, you can roll it back and
> try again until you’re successful – you never lose changes.

This I've legitimately never done. Merging with SVN is pretty nice, at
least I think so. You just go around resolving conflicts. Not so
tough. Don't disagree that it could be better, but I don't think there
is an issue here particularly.


> 3.   Merging in DVC’s works fantastically. By comparison the merging
> approaches of TFS and Subversion are broken. To even use a DVCS you’re using
> branching and merging, since the server and your local machine are entirely
> different repositories. In TFS and SVN, branching and merging is a scary
> concept only used in the most dire of circumstances.

Broken how?


> Those advantages apply in the most connected corporate environment – when
> I’m forced to use TFS I wish it had better support for these three features.
> Prior to using Mercurial I just accepted that the way SVN made me work was
> fine, and the occasional loss of code or busted merge was a fact of life.
> Now I find it frustrating to work with TFS/Subversion and sometimes wonder
> if a folder full of “copy of …”.zip files would be more effective J
>
> There are other advantages to do specifically with open source projects –
> for instance, instead of sending a patch, people can put their repository
> online to share with others, and you can cherry pick the changes you want
> from them. The patching system really fails once a patch gets a little old.

Right, I'm not interested in these, and neither are the majority of
small enterprises, I would venture. I don't deny it's a benefit, and
it's a good one, but not one that I care about.

Anyway, I do appreciate these comments, and I may actually take a
look, having been slightly convinced.


> Paul

-- 
silky

http://dnoondt.wordpress.com/

"Every morning when I wake up, I experience an exquisite joy — the joy
of being this signature."

RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[Paul Stovell]

Hi Silky,



I think in some ways you have to experience it - the proof is in the tasting. 
But here are some things I like about it that work even for small, local teams.



1.   How many times did you make a small change, then delete it and try 
something else, only to realize that you didn't check in during that time since 
it wasn't "ready" to share with the team? Since most of your interaction with 
source control is just to your hard disk, you're more likely to use it. On my 
current project with Mercurial I'm averaging a commit every 10 minutes - lots 
of small changes.

2.   How many times have you done an SVN update/TFS "get latest", tried to 
merge, made a mistake, and lost changes in the process? With Mercurial that 
doesn't happen -it forces you to commit your local changes first, then merge 
them with the server changes. If it fails, you can roll it back and try again 
until you're successful - you never lose changes.

3.   Merging in DVC's works fantastically. By comparison the merging 
approaches of TFS and Subversion are broken. To even use a DVCS you're using 
branching and merging, since the server and your local machine are entirely 
different repositories. In TFS and SVN, branching and merging is a scary 
concept only used in the most dire of circumstances.



Those advantages apply in the most connected corporate environment - when I'm 
forced to use TFS I wish it had better support for these three features. Prior 
to using Mercurial I just accepted that the way SVN made me work was fine, and 
the occasional loss of code or busted merge was a fact of life. Now I find it 
frustrating to work with TFS/Subversion and sometimes wonder if a folder full 
of "copy of ...".zip files would be more effective :)



There are other advantages to do specifically with open source projects - for 
instance, instead of sending a patch, people can put their repository online to 
share with others, and you can cherry pick the changes you want from them. The 
patching system really fails once a patch gets a little old.



Paul





-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of silky
Sent: Thursday, 4 November 2010 8:29 AM
To: ozDotNet
Subject: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?



On Thu, Nov 4, 2010 at 6:26 AM, Joseph Cooney 
mailto:joseph.coo...@gmail.com>> wrote:

> I've used TFS on and off since about 2006 (mostly because I was

> working at MS, as they are fond of TFS), but haven't used TFS 2010.

> It's biggest strength IMO is integration - requirements, work items,

> bugs, builds, source code and project documentation all from within

> Visual Studio. It's biggest weakness is that it's not a distributed

> version control system (git, mercurial).



Without sounding too argumentative; exactly why should I care that version 
control is "distributed"?



The stated arguments seem to be that you don't need to be online to do commits, 
or that there is a local history, or some other such things.

I really just don't ever find the need for anything like that; am I doing 
something significantly different to everyone else?



I mean, I've glanced over this:

http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/

and it seems none of the benefits are really appropriate in a 'typical' 
environment.



I guess what I'm asking is - is anyone, working in an office or alone, getting 
specific benefits from git or whatever, that come *purely* from it being 
significantly different from SVN, and exactly what are they?





> If you're just going to use it as a revision control system you're

> missing out on 80-90% of what TFS has to offer (and thus it might not

> be worth it). TFS 2010 is a major update to the product (v2 really,

> since

> 2008 was really a v1.1) so I'm doubtless overlooking some cool

> features there 'cause I haven't used it.

> 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."

RE: TFS Feedaback? Anyone moved away from it?

[Maddin, Peter]

We (both of us) are using TFS Workgroup edition basically for source code 
control only at present.
Will be using other features such as adding tasks for bugs etc when UA testing 
gets under way.

I am quite happy with it. Occasionally a few things do get screwed up due to 
our inexperience but we have not had any problems recovering from these (just 
sweated a bit).

Would like to use the other features but we don't have the time at present.

If we weren't using it we would be using Subversion of which I have heard good 
things.

Regards Peter Maddin
Applications Development Officer
PathWest Laboratory Medicine WA
Phone : +618 9473 3944
Fax : +618 9473 3982
E-Mail : peter.mad...@pathwest.wa.gov.au
The contents of this e-mail transmission outside of the WAGHS network are 
intended solely for the named recipient's), may be confidential, and may be 
privileged or otherwise protected from disclosure in the public interest. The 
use, reproduction, disclosure or distribution of the contents of this e-mail 
transmission by any person other than the named recipient(s) is prohibited. If 
you are not a named recipient please notify the sender immediately.

-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Les Hughes
Sent: Wednesday, 3 November 2010 8:32 PM
To: michaelsli...@gmail.com; ozDotNet
Subject: TFS Feedaback? Anyone moved away from it?

Hi All,

I was just looking to get a little feedback on CVS tools/etc?

I am to start another project with a small team, and was wondering is 
TFS is worth using (I haven't even seen it run yet... wondering if it is 
worth the time...)

Also, has anyone after using TFS decided to go back to subversion/etc? 
If so, why?

Thanks :)
--
Les Hughes
l...@datarev.com.au

RE: TFS Feedaback? Anyone moved away from it?

[Alastair Waddell]

Hi Les,

I have used a few (Source safe / TFS / Borland Starteam / Subversion) in
my dealings as a contractor, and have to say I am very happy with TFS.

I guess it all depends on what you are after - Just source control or
the full ALM?

At the office we use TFS 2008 to get bug tracking, reports etc, but for
my personal stuff I am using TFS2010 basic on a Windows home server just
for source control.

Install was a breeze and it just works! I can access everything remotely
and It feels like a first class citizen in VS.

I wouldn't consider going back myself.

That said though, we do have issues with TFS at the office with a team
of devs - but almost always it's the developer's actions that cause the
problems.

Things like changing files outside VS (so TFS doesn't know its changed),
or "overwriting" the server version instead of merging, leaving files
exclusively locked, and it has taken a bit of time to educate on good
"Project structure for source control" and the branching and merging
strategies, but these are going to be issues with any system.

It does help to have the power tools and I also use Team foundation
sidekicks to manage the office install.

So is it worth the time? - Yes


Alastair

-Original Message-
From: ozdotnet-boun...@ozdotnet.com
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Les Hughes
Sent: Wednesday, 3 November 2010 8:32 PM
To: michaelsli...@gmail.com; ozDotNet
Subject: TFS Feedaback? Anyone moved away from it?

Hi All,

I was just looking to get a little feedback on CVS tools/etc?

I am to start another project with a small team, and was wondering is
TFS is worth using (I haven't even seen it run yet... wondering if it is

worth the time...)

Also, has anyone after using TFS decided to go back to subversion/etc?
If so, why?

Thanks :)
--
Les Hughes
l...@datarev.com.au





Important Notice
This email contains information which is confidential and intended solely for 
the use of the individual or entity to whom it is addressed.  Please notify the 
sender immediately if you have received this e-mail by mistake and delete this 
email from your system.  If you are not the intended recipient, any form of 
distribution, copying or use of this communication or the information contained 
or attached is strictly prohibited.  Although Disability Services Commission 
has taken reasonable precautions to ensure no viruses are present in this 
email, the Commission cannot accept responsibility for any loss or damage 
arising from the use of this email or attachments.

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[silky]

On Thu, Nov 4, 2010 at 12:37 PM, Joseph Cooney  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 sure 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.

Okay, 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."

Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[Joseph Cooney]

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 sure 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.

High-level summary (from my POV) - DVCS well in a super-set of
configurations to old skool SVN/TFS/CVS

Joseph

On Thu, Nov 4, 2010 at 8:28 AM, silky  wrote:

> On Thu, Nov 4, 2010 at 6:26 AM, Joseph Cooney 
> wrote:
> > I've used TFS on and off since about 2006 (mostly because I was working
> at
> > MS, as they are fond of TFS), but haven't used TFS 2010. It's biggest
> > strength IMO is integration - requirements, work items, bugs, builds,
> source
> > code and project documentation all from within Visual Studio. It's
> biggest
> > weakness is that it's not a distributed version control system (git,
> > mercurial).
>
> Without sounding too argumentative; exactly why should I care that
> version control is "distributed"?
>
> The stated arguments seem to be that you don't need to be online to do
> commits, or that there is a local history, or some other such things.
> I really just don't ever find the need for anything like that; am I
> doing something significantly different to everyone else?
>
> I mean, I've glanced over this:
>
> http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
> and it seems none of the benefits are really appropriate in a
> 'typical' environment.
>
> I guess what I'm asking is - is anyone, working in an office or alone,
> getting specific benefits from git or whatever, that come *purely*
> from it being significantly different from SVN, and exactly what are
> they?
>
>
> > If you're just going to use it as a revision control system
> > you're missing out on 80-90% of what TFS has to offer (and thus it might
> not
> > be worth it). TFS 2010 is a major update to the product (v2 really, since
> > 2008 was really a v1.1) so I'm doubtless overlooking some cool features
> > there 'cause I haven't used it.
> > 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."
>



-- 

w: http://jcooney.net
t: @josephcooney

RE: TFS Feedaback? Anyone moved away from it?

[Dylan Tusler]

We're in the process of migrating from TFS 2008 to TFS 2010. I don't think we'd 
look at any other system now. We use the work item integration with source code 
control quite heavily, even though the dev team is quite small. We also use 
modified work item for our Change Control system, and that has worked out well 
too.

We have even used the Sharepoint repositories a bit, though somewhat 
sporadically, and for a couple of projects we've even used the build server, 
for which I was quite grateful.

Previously we had a mix of SourceSafe and CVS in use here.

There is definitely an improvement in TFS2010 in terms of Work Item 
hierarchies, that we have been sorely missing here. Looking forward to it!

Dylan.


 

-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Les Hughes
Sent: Wednesday, 3 November 2010 10:32 PM
To: michaelsli...@gmail.com; ozDotNet
Subject: TFS Feedaback? Anyone moved away from it?

Hi All,

I was just looking to get a little feedback on CVS tools/etc?

I am to start another project with a small team, and was wondering is TFS is 
worth using (I haven't even seen it run yet... wondering if it is worth the 
time...)

Also, has anyone after using TFS decided to go back to subversion/etc? 
If so, why?

Thanks :)
--
Les Hughes
l...@datarev.com.au

-
To find out more about the Sunshine Coast Regional Council, visit your local 
office at Caloundra, Maroochydore, Nambour or Tewantin or visit us online at 
www.sunshinecoast.qld.gov.au.  If correspondence includes personal information, 
please refer to Council's Privacy Policy at http://www.sunshinecoast.qld.gov.au 
.

This email and any attachments are confidential and only for the use of the 
addressee.  If you have received this email in error you are requested to 
notify the sender by return email or contact council on 1300 00 7272 and are 
prohibited from forwarding, printing, copying or using it in anyway, in whole 
or part. Please note that some council staff utilise Blackberry devices, which 
results in information being transmitted overseas prior to delivery of any 
communication to the device.  In sending an email to Council you are agreeing 
that the content of your email may be transmitted overseas. Any views expressed 
in this email are the author's, except where the email makes it clear 
otherwise. The unauthorised publication of an email and any attachments 
generated for the official functions of council is strictly prohibited. Please 
note that council is subject to the Right to Information Act 2009 (Qld) and 
Information Privacy Act 2009 (Qld).

Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[silky]

On Thu, Nov 4, 2010 at 6:26 AM, Joseph Cooney  wrote:
> I've used TFS on and off since about 2006 (mostly because I was working at
> MS, as they are fond of TFS), but haven't used TFS 2010. It's biggest
> strength IMO is integration - requirements, work items, bugs, builds, source
> code and project documentation all from within Visual Studio. It's biggest
> weakness is that it's not a distributed version control system (git,
> mercurial).

Without sounding too argumentative; exactly why should I care that
version control is "distributed"?

The stated arguments seem to be that you don't need to be online to do
commits, or that there is a local history, or some other such things.
I really just don't ever find the need for anything like that; am I
doing something significantly different to everyone else?

I mean, I've glanced over this:
http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
and it seems none of the benefits are really appropriate in a
'typical' environment.

I guess what I'm asking is - is anyone, working in an office or alone,
getting specific benefits from git or whatever, that come *purely*
from it being significantly different from SVN, and exactly what are
they?


> If you're just going to use it as a revision control system
> you're missing out on 80-90% of what TFS has to offer (and thus it might not
> be worth it). TFS 2010 is a major update to the product (v2 really, since
> 2008 was really a v1.1) so I'm doubtless overlooking some cool features
> there 'cause I haven't used it.
> 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."

Re: TFS Feedaback? Anyone moved away from it?

[Joseph Cooney]

I've used TFS on and off since about 2006 (mostly because I was working at
MS, as they are fond of TFS), but haven't used TFS 2010. It's biggest
strength IMO is integration - requirements, work items, bugs, builds, source
code and project documentation all from within Visual Studio. It's biggest
weakness is that it's not a distributed version control system (git,
mercurial). If you're just going to use it as a revision control system
you're missing out on 80-90% of what TFS has to offer (and thus it might not
be worth it). TFS 2010 is a major update to the product (v2 really, since
2008 was really a v1.1) so I'm doubtless overlooking some cool features
there 'cause I haven't used it.

Joseph

On Wed, Nov 3, 2010 at 10:31 PM, Les Hughes  wrote:

> Hi All,
>
> I was just looking to get a little feedback on CVS tools/etc?
>
> I am to start another project with a small team, and was wondering is TFS
> is worth using (I haven't even seen it run yet... wondering if it is worth
> the time...)
>
> Also, has anyone after using TFS decided to go back to subversion/etc? If
> so, why?
>
> Thanks :)
> --
> Les Hughes
> l...@datarev.com.au
>



-- 

w: http://jcooney.net
t: @josephcooney