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 <[email protected]> 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: [email protected] [mailto:[email protected]] > 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: [email protected] [mailto:[email protected]] > 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 <[email protected]> > 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." > > > > ********************************************************************************************** > Important Note > This email (including any attachments) contains information which is > confidential and may be subject to legal privilege. If you are not the > intended recipient you must not use, distribute or copy this email. If you > have received this email in error please notify the > sender immediately and delete this email. Any views expressed in this email > are not necessarily the views of IRESS Market Technology Limited. > > It is the duty of the recipient to virus scan and otherwise test the > information provided before loading onto any computer system. > IRESS Market Technology Limited does not warrant that the information is > free of a virus or any other defect or error. > > ********************************************************************************************** > >
