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