Re: TFS Build in the Cloud
Grant/David Thank you for putting me through. Chris I'll email you directly. On 21 February 2014 05:58, David Kean wrote: > Adding Chris and Grant's replies. > > > > *From:* Chris Patterson > *Sent:* Thursday, February 20, 2014 5:28 AM > *To:* Grant Holliday; David Kean; ozDotNet > *Subject:* RE: TFS Build in the Cloud > > > > I haven't really considered it because it is outside the realm of the vast > majority of the users that I have encountered. I don't specifically know > of any compatibility or SxS issues, but it is always possible. > > > > *From:* Grant Holliday > *Sent:* Wednesday, February 19, 2014 7:33 PM > *To:* David Kean; ozDotNet; Chris Patterson > *Subject:* RE: TFS Build in the Cloud > > > > Chris owns this area. > > > > Chris - Have we considered adding SSDT-BI tools to the Hosted Build image? > > > http://blogs.msdn.com/b/analysisservices/archive/2013/03/06/sql-server-data-tools-business-intelligence-for-visual-studio-2012-released-online.aspx > > > > > > *From:* David Kean > *Sent:* Thursday, 20 February 2014 10:35 AM > *To:* ozDotNet; Grant Holliday > *Subject:* RE: TFS Build in the Cloud > > > > Grant? > > > > *From:* ozdotnet-boun...@ozdotnet.com [ > mailto:ozdotnet-boun...@ozdotnet.com ] *On > Behalf Of *Preet Sangha > *Sent:* Wednesday, February 19, 2014 3:01 PM > *To:* ozDotNet > *Subject:* TFS Build in the Cloud > > > > Does anyone know who would be the best person/team to contact at Microsoft > in order to request some extra software (MS SSDT-BI components) be > installed on the Azure based VisualStudio.com build servers? > > > > It seems that though SSDT is installed - SSDT-BI is still left out. In > fact I'm completely open to the idea that it couldn't be installed due to > some incompatibility - in which case I'd rather avoid going down the road > of building my own build server simply to run into that road block! > > > > -- > regards, > Preet, Overlooking the Ocean, Auckland > -- regards, Preet, Overlooking the Ocean, Auckland
RE: TFS Build in the Cloud
Adding Chris and Grant's replies. From: Chris Patterson Sent: Thursday, February 20, 2014 5:28 AM To: Grant Holliday; David Kean; ozDotNet Subject: RE: TFS Build in the Cloud I haven't really considered it because it is outside the realm of the vast majority of the users that I have encountered. I don't specifically know of any compatibility or SxS issues, but it is always possible. From: Grant Holliday Sent: Wednesday, February 19, 2014 7:33 PM To: David Kean; ozDotNet; Chris Patterson Subject: RE: TFS Build in the Cloud Chris owns this area. Chris - Have we considered adding SSDT-BI tools to the Hosted Build image? http://blogs.msdn.com/b/analysisservices/archive/2013/03/06/sql-server-data-tools-business-intelligence-for-visual-studio-2012-released-online.aspx From: David Kean Sent: Thursday, 20 February 2014 10:35 AM To: ozDotNet; Grant Holliday Subject: RE: TFS Build in the Cloud Grant? From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Preet Sangha Sent: Wednesday, February 19, 2014 3:01 PM To: ozDotNet Subject: TFS Build in the Cloud Does anyone know who would be the best person/team to contact at Microsoft in order to request some extra software (MS SSDT-BI components) be installed on the Azure based VisualStudio.com build servers? It seems that though SSDT is installed - SSDT-BI is still left out. In fact I'm completely open to the idea that it couldn't be installed due to some incompatibility - in which case I'd rather avoid going down the road of building my own build server simply to run into that road block! -- regards, Preet, Overlooking the Ocean, Auckland
RE: TFS Build in the Cloud
Grant? From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Preet Sangha Sent: Wednesday, February 19, 2014 3:01 PM To: ozDotNet Subject: TFS Build in the Cloud Does anyone know who would be the best person/team to contact at Microsoft in order to request some extra software (MS SSDT-BI components) be installed on the Azure based VisualStudio.com build servers? It seems that though SSDT is installed - SSDT-BI is still left out. In fact I'm completely open to the idea that it couldn't be installed due to some incompatibility - in which case I'd rather avoid going down the road of building my own build server simply to run into that road block! -- regards, Preet, Overlooking the Ocean, Auckland
RE: Tfs
Yes it is normal (and annoying). You just have to ignore the file. If it doesn't change, TFS won't actually check it in (it skips it under the covers if using the UI, if using the command-line it will tell you that it didn't check it in). They are looking at making this experience better in a future version. From: ozdotnet-boun...@ozdotnet.com [ozdotnet-boun...@ozdotnet.com] on behalf of djones...@gmail.com [djones...@gmail.com] Sent: Wednesday, March 30, 2011 1:10 AM To: ozDotNet Subject: Tfs Hi guys, Recently work has switched from clearcase to tfs. The only problem is when I go to check in, it tries to check in all the .vsspscc files as well. Is this normal for tfs? Or is it a configuration problem, and if so server or client? This is the first time I've used it as before it was always subversion / git etc. Thanks Davy "When all you have is a hammer, every problem looks like a nail." I feel much the same way about xml
RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
>> 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?
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?
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 its 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?
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?
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?
>> 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?
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?
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?
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?
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?
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?
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?
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?
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?
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
Re: TFS for small projects?
You may be asking for a religious flame war with a question like this. TFS would be the last option i'd consider for almost any project. If you're talking about an open source project, i'd use github, bitbucket, codeplex or google code. github uses git. bitbucket uses mercurial. codeplex supports svn and now mercurial. google code supports svn and mercurial. subversion is probably the simplest and most convenient of centralised version control systems. distributed version control (hg and git - and others) is just so much more convenient you'll wonder how you ever lived without it. If you're talking about a closed source project, i'd recommend a private repository to github or bitbucket - they both have reasonable issue tracking systems and wikis. There are also independent issue tracking systems such as http://lighthouseapp.com/ that are really good if you just want to stick with the version control that you already have. If you're really wanting user feedback rather than bug tracking, there are other systems like http://getsatisfaction.com/. On Fri, Mar 5, 2010 at 1:00 AM, Matt Siebert wrote: > Hi all, > > I have a smallish project I'm working on in my spare time. I'm the only > developer and it's been slow going since I don't have a lot of spare time. > > So far I've just been using subversion for source control and nothing in > particular for issue tracking and project management. The project is really > beginning to gain momentum and I'll likely have to commit a lot more time to > it fairly soon so I want to get some systems in place before we go too far. > > With the inclusion of a TFS license in the upcoming changes to MSDN > subscriptions I'm considering using TFS but don't know a lot about it beyond > some marketing BS I read on a pretty brochure a while ago, and some vague > horror stories I've heard about installing and configuring it. > > Does TFS really offer much benefit for a smallish project, or is it > overkill? > > Can my client use it to report and track issues? Would we need to purchase > any additional licenses? > > Do I have to use it's source control or can I stick with subversion? (am I > crazy for considering this?) > > A while ago I did look at Countersoft's Gemini for issue tracking but as > the project didn't really have any issues to track I didn't spend much time > on it. > > Thanks, > Matt. >
Re: TFS without an IDE
That is correct. Regardless of that, it is an appropriate choice where you want to give a non-developer access to TFS. You can install it as a free stand alone tool. On Thu, Mar 4, 2010 at 9:06 AM, Preet Sangha wrote: > Its just 'visual studio' init :-) But with out the language services... > > On 4 March 2010 12:01, ross wrote: >> >> You can just use "team explorer". It is a free gui that looks like VS >> but only allows tfs activities. >> >> >> http://www.microsoft.com/downloads/details.aspx?FamilyID=0ed12659-3d41-4420-bbb0-a46e51bfca86&displaylang=en >> >> On Thu, Mar 4, 2010 at 8:39 AM, Grant Molloy wrote: >> > Thanks for that Mike.. >> > I'll clarify further... >> > We have some "analysts" who are working on a project that want to use >> > our >> > source code repository.. Given the unknown level of skill, or even >> > common >> > sense, I was looking for a GUI application as opposed to a command line >> > tool.. >> > Maybe could whip something up!!! >> > Has anyone done anything to wrap the TF.exe in a GUI ?? >> > >> > On Thu, Mar 4, 2010 at 8:34 AM, Mike Liddell >> > >> > wrote: >> >> >> >> Command-line tools are standard with tfs. >> >> eg: >> >> >> >> Ø tf edit filename. >> >> >> >> Ø Reference: >> >> http://msdn.microsoft.com/en-us/library/cc31bk2e(VS.80).aspx >> >> >> >> Ø tf.exe should be on your path, or locatable in Program Files >> >> >> >> >> >> >> >> Also get your hands on the TFS power tools (to get tfpt.exe which has >> >> some >> >> excellent goodies) >> >> >> >> Eg http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx >> >> >> >> >> >> >> >> -mike >> >> >> >> From: ozdotnet-boun...@ozdotnet.com >> >> [mailto:ozdotnet-boun...@ozdotnet.com] >> >> On Behalf Of Grant Molloy >> >> Sent: Wednesday, March 03, 2010 2:30 PM >> >> To: ozdotnet@ozdotnet.com >> >> Subject: TFS without an IDE >> >> >> >> >> >> >> >> Hi list, >> >> >> >> >> >> >> >> Does anyone use any tools which allow you to check files in and out of >> >> TFS >> >> without having to use Team Explorer in Visual Studio ? >> >> >> >> ___ >> >> ozdotnet mailing list >> >> ozdotnet@ozdotnet.com >> >> http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet >> >> >> > >> > >> > ___ >> > ozdotnet mailing list >> > ozdotnet@ozdotnet.com >> > http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet >> > >> > >> ___ >> ozdotnet mailing list >> ozdotnet@ozdotnet.com >> http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet > > > > -- > regards, > Preet, Overlooking the Ocean, Auckland > > ___ > ozdotnet mailing list > ozdotnet@ozdotnet.com > http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet > > ___ ozdotnet mailing list ozdotnet@ozdotnet.com http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet
Re: TFS without an IDE
Its just 'visual studio' init :-) But with out the language services... On 4 March 2010 12:01, ross wrote: > You can just use "team explorer". It is a free gui that looks like VS > but only allows tfs activities. > > > http://www.microsoft.com/downloads/details.aspx?FamilyID=0ed12659-3d41-4420-bbb0-a46e51bfca86&displaylang=en > > On Thu, Mar 4, 2010 at 8:39 AM, Grant Molloy wrote: > > Thanks for that Mike.. > > I'll clarify further... > > We have some "analysts" who are working on a project that want to use our > > source code repository.. Given the unknown level of skill, or even common > > sense, I was looking for a GUI application as opposed to a command line > > tool.. > > Maybe could whip something up!!! > > Has anyone done anything to wrap the TF.exe in a GUI ?? > > > > On Thu, Mar 4, 2010 at 8:34 AM, Mike Liddell > > > wrote: > >> > >> Command-line tools are standard with tfs. > >> eg: > >> > >> Ø tf edit filename. > >> > >> Ø Reference: > http://msdn.microsoft.com/en-us/library/cc31bk2e(VS.80).aspx > >> > >> Ø tf.exe should be on your path, or locatable in Program Files > >> > >> > >> > >> Also get your hands on the TFS power tools (to get tfpt.exe which has > some > >> excellent goodies) > >> > >> Eg http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx > >> > >> > >> > >> -mike > >> > >> From: ozdotnet-boun...@ozdotnet.com [mailto: > ozdotnet-boun...@ozdotnet.com] > >> On Behalf Of Grant Molloy > >> Sent: Wednesday, March 03, 2010 2:30 PM > >> To: ozdotnet@ozdotnet.com > >> Subject: TFS without an IDE > >> > >> > >> > >> Hi list, > >> > >> > >> > >> Does anyone use any tools which allow you to check files in and out of > TFS > >> without having to use Team Explorer in Visual Studio ? > >> > >> ___ > >> ozdotnet mailing list > >> ozdotnet@ozdotnet.com > >> http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet > >> > > > > > > ___ > > ozdotnet mailing list > > ozdotnet@ozdotnet.com > > http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet > > > > > ___ > ozdotnet mailing list > ozdotnet@ozdotnet.com > http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet > -- regards, Preet, Overlooking the Ocean, Auckland ___ ozdotnet mailing list ozdotnet@ozdotnet.com http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet
Re: TFS without an IDE
You can just use "team explorer". It is a free gui that looks like VS but only allows tfs activities. http://www.microsoft.com/downloads/details.aspx?FamilyID=0ed12659-3d41-4420-bbb0-a46e51bfca86&displaylang=en On Thu, Mar 4, 2010 at 8:39 AM, Grant Molloy wrote: > Thanks for that Mike.. > I'll clarify further... > We have some "analysts" who are working on a project that want to use our > source code repository.. Given the unknown level of skill, or even common > sense, I was looking for a GUI application as opposed to a command line > tool.. > Maybe could whip something up!!! > Has anyone done anything to wrap the TF.exe in a GUI ?? > > On Thu, Mar 4, 2010 at 8:34 AM, Mike Liddell > wrote: >> >> Command-line tools are standard with tfs. >> eg: >> >> Ø tf edit filename. >> >> Ø Reference: http://msdn.microsoft.com/en-us/library/cc31bk2e(VS.80).aspx >> >> Ø tf.exe should be on your path, or locatable in Program Files >> >> >> >> Also get your hands on the TFS power tools (to get tfpt.exe which has some >> excellent goodies) >> >> Eg http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx >> >> >> >> -mike >> >> From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] >> On Behalf Of Grant Molloy >> Sent: Wednesday, March 03, 2010 2:30 PM >> To: ozdotnet@ozdotnet.com >> Subject: TFS without an IDE >> >> >> >> Hi list, >> >> >> >> Does anyone use any tools which allow you to check files in and out of TFS >> without having to use Team Explorer in Visual Studio ? >> >> ___ >> ozdotnet mailing list >> ozdotnet@ozdotnet.com >> http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet >> > > > ___ > ozdotnet mailing list > ozdotnet@ozdotnet.com > http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet > > ___ ozdotnet mailing list ozdotnet@ozdotnet.com http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet
Re: TFS without an IDE
The new TFS power tools have a window explorer interface. The TFS command line is also cool On 4 March 2010 11:39, Grant Molloy wrote: > Thanks for that Mike.. > > I'll clarify further... > We have some "analysts" who are working on a project that want to use our > source code repository.. Given the unknown level of skill, or even common > sense, I was looking for a GUI application as opposed to a command line > tool.. > > Maybe could whip something up!!! > Has anyone done anything to wrap the TF.exe in a GUI ?? > > > On Thu, Mar 4, 2010 at 8:34 AM, Mike Liddell > wrote: > >> Command-line tools are standard with tfs. >> eg: >> >> Ø tf edit filename. >> >> Ø Reference: >> http://msdn.microsoft.com/en-us/library/cc31bk2e(VS.80).aspx >> >> Ø tf.exe should be on your path, or locatable in Program Files >> >> >> >> Also get your hands on the TFS power tools (to get tfpt.exe which has some >> excellent goodies) >> >> Eg http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx >> >> >> >> -mike >> >> *From:* ozdotnet-boun...@ozdotnet.com [mailto: >> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Grant Molloy >> *Sent:* Wednesday, March 03, 2010 2:30 PM >> *To:* ozdotnet@ozdotnet.com >> *Subject:* TFS without an IDE >> >> >> >> Hi list, >> >> >> >> Does anyone use any tools which allow you to check files in and out of TFS >> without having to use Team Explorer in Visual Studio ? >> >> ___ >> ozdotnet mailing list >> ozdotnet@ozdotnet.com >> http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet >> >> > > ___ > ozdotnet mailing list > ozdotnet@ozdotnet.com > http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet > > -- regards, Preet, Overlooking the Ocean, Auckland ___ ozdotnet mailing list ozdotnet@ozdotnet.com http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet
Re: TFS without an IDE
Thanks for that Mike.. I'll clarify further... We have some "analysts" who are working on a project that want to use our source code repository.. Given the unknown level of skill, or even common sense, I was looking for a GUI application as opposed to a command line tool.. Maybe could whip something up!!! Has anyone done anything to wrap the TF.exe in a GUI ?? On Thu, Mar 4, 2010 at 8:34 AM, Mike Liddell wrote: > Command-line tools are standard with tfs. > eg: > > Ø tf edit filename. > > Ø Reference: http://msdn.microsoft.com/en-us/library/cc31bk2e(VS.80).aspx > > Ø tf.exe should be on your path, or locatable in Program Files > > > > Also get your hands on the TFS power tools (to get tfpt.exe which has some > excellent goodies) > > Eg http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx > > > > -mike > > *From:* ozdotnet-boun...@ozdotnet.com [mailto: > ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Grant Molloy > *Sent:* Wednesday, March 03, 2010 2:30 PM > *To:* ozdotnet@ozdotnet.com > *Subject:* TFS without an IDE > > > > Hi list, > > > > Does anyone use any tools which allow you to check files in and out of TFS > without having to use Team Explorer in Visual Studio ? > > ___ > ozdotnet mailing list > ozdotnet@ozdotnet.com > http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet > > ___ ozdotnet mailing list ozdotnet@ozdotnet.com http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet
RE: TFS without an IDE
Command-line tools are standard with tfs. eg: Ø tf edit filename. Ø Reference: http://msdn.microsoft.com/en-us/library/cc31bk2e(VS.80).aspx Ø tf.exe should be on your path, or locatable in Program Files Also get your hands on the TFS power tools (to get tfpt.exe which has some excellent goodies) Eg http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx -mike From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Grant Molloy Sent: Wednesday, March 03, 2010 2:30 PM To: ozdotnet@ozdotnet.com Subject: TFS without an IDE Hi list, Does anyone use any tools which allow you to check files in and out of TFS without having to use Team Explorer in Visual Studio ? ___ ozdotnet mailing list ozdotnet@ozdotnet.com http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet
