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 david.k...@microsoft.com 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 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] 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 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
Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?
On Sun, Nov 7, 2010 at 10:23 AM, Joseph Cooney joseph.coo...@gmail.com 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?
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 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?
On Thu, Nov 4, 2010 at 6:10 PM, Paul Stovell paul.stov...@readify.net 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?
time waste - no real info 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. /time waste - no real info On Thu, Nov 4, 2010 at 6:30 PM, silky michaelsli...@gmail.com wrote: On Thu, Nov 4, 2010 at 6:10 PM, Paul Stovell paul.stov...@readify.net 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?
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 5 November 2010 08:37, mike smith meski...@gmail.com 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?
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 paul.stov...@readify.net 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
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 druss...@iress.com.au 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...@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 paul.stov...@readify.net 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
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 michaelsli...@gmail.com wrote: On Fri, Nov 5, 2010 at 10:54 AM, Grant Molloy graken...@gmail.com 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 5 November 2010 09:55, David Connors da...@codify.com wrote: On 5 November 2010 08:37, mike smith meski...@gmail.com 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?
On 5 November 2010 10:59, silky michaelsli...@gmail.com wrote: On Fri, Nov 5, 2010 at 10:54 AM, Grant Molloy graken...@gmail.com 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 Fri, Nov 5, 2010 at 12:42 PM, mike smith meski...@gmail.com wrote: On 5 November 2010 10:59, silky michaelsli...@gmail.com wrote: On Fri, Nov 5, 2010 at 10:54 AM, Grant Molloy graken...@gmail.com 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.
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?
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 l...@datarev.com.au 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
Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?
On Thu, Nov 4, 2010 at 6:26 AM, Joseph Cooney 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'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).
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 michaelsli...@gmail.com wrote: On Thu, Nov 4, 2010 at 6:26 AM, Joseph Cooney 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. -- w: http://jcooney.net t: @josephcooney
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: 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
