how is TFS these days?

[Justin Collum]

Say someone is looking at a job. Job uses TFS as source control. That someone has had bad experiences with TFS in the past. Has it improved? Is it still kind of a wacky, hard-to-work with source control? 

Personally, it seemed half-baked (from just the VCS standpoint) last time I used it. I tried to find an example of using externals (like SVN's extern) and didn't find much -- guess there's a 'baseless merge' that is ... similar-ish. http://stackoverflow.com/questions/6540079/tfs-2010-how-to-handle-external-branched-in-dependencies-on-working-branches

 

[Jen Turay]

Personally, I don't find it difficult to work with at all. We've been using TFS 2010 for nearly a year now and I very much enjoy it.  It is much improved over TFS 2008..  And really - no comparison to the 2005 version.  I find it much more intuitive to work with than SVN.  Then, I do most of my work inside of Visual Studio..  with the built-in integration, there really is no better way to go.  When working with other utilities..  they pushed out the Power Tools which allows one to access Source Control functionality through Windows Explorer. 

 

I like it.  Then again, I am the TFS admin at my job.  So I guess I'm a little biased. ;)

[Eric Williams]

It is still terrible.  Up until two months ago I was using it since 2005.  Been using git and have never been happier.  Not because it is the shinny thing but because of the workflows it enables.  I started DVCS with Hg and it was fine but the branching model didn't feel right after testing out git on a couple of projects.  Since then I've moved most of my little projects from BitBucket over to github.  I haven't tried Eric Sink's Veracity yet and I doubt I will since well I'm happy with what I'm on.

If you do get stuck with TFS use the Git-TFS bridge so that you still use a local branch-per-feature.

-Eric

PS TFS is terrible.

[Adron Hall]

Git to tfs is your salvation.  Otherwise its still the same old TFS hell.   =(

[John Weldon]

I'm using TFS for the first time in the last couple months.  After using mercurial and before that subversion, TFS does feel limiting.  The caveats are: 1) I don't like Visual Studio integration with source control.  I know this is a personal preference thing.  Some people love it.  2)  I think TFS requires a bit of a shift in the way you think about source control.  I've come to deeply appreciate and even love DVCS, so I just don't like TFS, but I think it's a pretty good product for it's sphere.

I agree with TFS Powertools being a lifesaver.  It helps me most with merging shelvesets, etc. 

Also, I've been using git-tfs, and it's great.  Still has a few warts, but I think it's very usable as a compromise between DVCS, and TFS.

Cheers,

--
John Weldon

[Adron Hall]

This is one of those major TFS flaws. Please don't think I'm harping on anyone in particular, but just the fact that TFS needs an "administrator" is insane!! But that's just one of the complexities of that system. Often once it is setup, it still doesn't totally work. The reports fail, or the database gets corrupted, or the users disappear, or worse some code doesn't check in right even though it "thinks" it has the code.

On another note, related to TFS, the actual BUILD of the product at Microsoft STILL has errors that they just ignore. Considered "acceptable" risk for shipment of the product. I don't know about you guys, but if I was in charge of a project and it had build errors for certain parts of it, I'd get those fixed.

Yes, TFS has improved dramatically over the years, but that's good and bad. Bad that it is still as clunky as it is after 5+ years being in development. Good that it has improved, but even then it is by no means a leader in the ALM Market for quality and availability/usability.

As mentioned, someone often has to "administer" the product, or as I often refer to it as "babysitting" the product. When the product, in tech terms, is a full grown adult. There should be no real babysitting going on!

Ok, I'm gonna shutup now. I know I'm a bit harsh on TFS, but there are reasons. I have seen that product almost crash a burn projects before, fortunately one can copy their code OUT of the product.  ;)

Cheers!
Adron

PS - I reiterate the awesomeness that is Git-TFS Bridge. At least when TFS hoses something up you'll have your beautifully historically accurate local repo. I rest easy when I have use a non distributed source control system these days, knowing that my local distributed source control client system will compensate for the non-distributed system.  :)

--
Adron B Hall

Tech: http://compositecode.com
Transit:  http://transitsleuth.com
Twitter: http://www.twitter.com/adron

[Justin Collum]

So TFS has a truck factor of ~1? Wow. What I'm saying is that if the Admin is on vacation and the code doesn't check in... well then what? That's a new one for source control. Corrupted database makes me think of SourceSafe -- not good. 

Last job I was at that used TFS had a TFS Admin as well. It was odd -- there were a few times that I needed something done and had to go find the Admin. A bit too vertical for my tastes. 

Thanks for the input guys. 

[Craig Wagner]

I'm definitely not a TFS fanboy, there are plenty of things it could do better, but I've been using it for 18 months now and it does the job. I wish it were more like SVN where it used the local working copy to determine changes instead of its own database, as we've been bit a couple of times because files haven't been explicitly added to the repository. TFS 11 is supposed to provide that as an option and I'm hoping we can move to that model as it will alleviate most, if not all, of the "TFS thought I had the most recent copy when I really didn't" problems we've encountered.

If I were starting from scratch I'd be more likely to push for SVN over TFS, but if you're already using it it does the job and it does it a heck of a lot better than VSS. And we've never had lost users or database corruption, and we branch off trunk for each release and then merge back when the release goes out, so we are doing a fair bit of branching/merging.

--
Craig Wagner
"An expert is someone who is one page ahead of you in the instruction manual."

[Justin Collum]

I remember seeing "TFS thought I had the most recent copy when I really didn't" a lot. Does it screw up your deployments? 

[Jen Turay]

As the system administrator, I answer questions about the tool and grant people access.  Our primary business is healthare - not development - so access is not open to the entire organization.  But my primary job is as a developer - administering this system is merely one task in my bucket.  And it's not a heavy task.  The system runs itself.  I patch it when service packs come out..  Today, I answered a question about a work item state..  It really isn't unreliable at all.  The system gets rebooted only when the servers are patched.

 

There are times when questions come up about how to interact with the system..  In that regards, there are some potential gaps.  But we've created some strong guidance regarding working with the tool - branching and merging is one example. 

 

I'm not saying it is the end-all-be-all..  but I just had to speak up and defend my "admin" comment.  This is definately one of the more reliable applications that we support in our business.

[Eric Williams]

The statement that TFS will go corrupt on the drop of a dime is way over blown - I also don't see how source control would torpedo a project if it is setup correctly.  Like I said before, I've been on 3 versions.  I've been through in-place upgrades, server to server migrations and single server to n-tier migrations with TFS and the infrastructure has never been a problem.  Even I won't put TFS in same sentence with Visual SourceSafe ... other then just now.

When leveraging any system that has its data store in a RDBMS you have to back them up on a regular basis.  This is the regular care and feeding of any system in that category.  Same goes for DVCS in that once you go beyond the level 0 instance of having your DVCS repo on a local/network file system to serve up those repos over http or ssh protocol then you're already taking on some admin tasks.  My point there is nothing is really admin free.  TFS Admin (on codeplex) makes user procurement dead simple and proper DR strategy makes it reliable.

I still don't like TFS but FUD is more annoying.

The TFS team is looking for feedback on using DVCS inside of TFS: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2312852-enable-distributed-source-control-dvcs (please go upvote the feathers out of that item) this should be interesting to you from the aspect "a rising tide lifts all boats".   If we can plug a git/hg into TFS then we can improve the quality of life for those developers who live in those MS only worlds - these worlds exists and they're not going away anytime soon.  That also opens the door to fixing the project system with regards to TFS in that the source control bindings become part of your solution and project file, which frankly sucks.

-Eric

[Lee Harding]

I'm not a fan of TFS (in fact, I've never used it), but I tend to agree with Eric's line of thinking.  

My take on this entire thread boils down to "If what version control system is in place is a big factor for a potential job, then don't take it."  I would hope that in any results-oriented team environment (which should mean everything Agile, right?) the amount of effort spent worrying about version control (and any other "resultless" process) should be minimal.  If it's not, the core problem is on the other side of the screen from the tools.

Or, more succinctly, the tool only matters if the team is lost.

[Craig Wagner]

No, it doesn't mess up deployments. We have a dedicated build server and it does a full get of the source prior to each build. It's only ever been a problem on developer machines where we don't do a full overwrite on each get, and even then only rarely (as in < once a month). When it does happen it's just incredibly annoying, particularly when the solution still builds but gives wrong results.

I'm mostly like Eric, "... FUD is more annoying." As I said, I probably wouldn't pick TFS for a greenfield project, but in our environment it gets the job done and there's really no good business reason to incur the cost of switching.

[Christopher Wright]

I'm a TFS Admin in a world of Microsoftaphobics. 

 

Personally, I really like the product.  It has come a long way since the Team System of 2005.  I would choose it over a collection of disparate tools any day, even if said tools are open source and free*.  I'm finding ways to make it work for Java and Oracle devs as well.  The drawback for me is training people to use TFS's Work Items to work for the Agile methodology - there is a definite learning curve.

 

- Chris

 

* see Robert A Heinlein's TANSTAAFL

On Tue, Nov 8, 2011 at 10:39 AM, Eric Williams <ericwil...@gmail.com> wrote:

--

Thanks,

 

Chris

[Justin Collum]

the amount of effort spent worrying about version control (and any other "resultless" process) should be minimal

I can't agree with that. I've seen plenty of instances of teams burning up time that they would otherwise spend on a resultful (yes I just made that up) process fighting with their tools. Source control, deployment tools, broken builds etc. Tools can throw up friction or they can make your life easier.

[Troy Howard]

I completely agree Justin.. A one time migration to a better VCS is
worth the time spent in "reduced friction development".

My advise regarding the job situation: Discuss it at the interview.
Find out if they are fanatics about TFS or just using it because it
seemed like a good idea. You could be the new guy that opens their
minds to Mercurial or Git. Private Bitbucket hosting is very cheap,
and "just works" so you don't have to have additional in-house IT load
for backups etc.. And it means you've got access to your VCS
repository outside of the company intranet without any complicated
network security shenanigans -- a good thing.

Thanks,
Troy

[Lee Harding]

the amount of effort spent worrying about version control (and any other "resultless" process) should be minimal

I can't agree with that. I've seen plenty of instances of teams burning up time that they would otherwise spend on a resultful (yes I just made that up) process fighting with their tools. Source control, deployment tools, broken builds etc. Tools can throw up friction or they can make your life easier.

If I'm a logger, you could say that a cross-cut saw is a "high friction" tool, and gets in the way of my job. A chainsaw would be superior choice -- if the goal of my organization is to cut down as many trees as possible.  To me software isn't like this "old school" view of logging, it's a little more like the practices of sustainable forest management -- very little time in which is spent cutting down trees.  Selecting which trees to cut, and keeping the ones still standing healthy dominates a forester's time these days.  Likewise, since MS (and others) have been so damn good at making tools, much more of my effort is on making the right choices than managing the tools or the code.

But I think we'll just disagree on this point, probably because we develop different kinds of software.  And, as expected, different kinds of software imply different practices.  Optimization, I think they call that.

As way of background, I offer this: My personal source code repository dates back 15 years, contains thousands of revisions and something like a quarter million lines of my code.  The largest single code repository I've worked with went back to 1988 and contained tens of millions of lines of actively developed code at HEAD.  Neither in my personal code, nor that monster did worry about which tools to use factor greatly into the products being delivered.

VSS, P4, SVN, CVS and some others I've forgotten have all worked for me at different times.  VSS had a bad habit of eating history, which made in untenable.  P4 was expensive.  Other than that, I never gave it much thought.

[Justin Collum]

No one ever said the tools were open source, free *and* easy. If you want easy and has a nice GUI, you'll probably have to pay for it. So there's your TANSTAAFL: easy isn't free and free isn't easy. 

What's the extern story like on TFS these days? I recall looking to put some code in a common place in 09 when I worked with TFS and the answer was "uhh, it doesn't really do that". That struck me as a Big Problem and a big violation of DRY. I read a bit about it on stackoverflow and I guess that sharing code is done via branches? So while most VCS has branches and tags, TFS has branches and branches? That's confusing. I recall that there are tags, but a quick search shows that they don't work the same way (e.g. a label can be deleted in the future). 

[Adron Hall]

It makes me wonder, what does Git to TFS do for branches.  Git is stupidly fast at branching, TFS is not, and in addition TFS basically copies the entire repo, which is also cumbersome and... well I won't go down that route.  So it makes me wonder, when you have a fast system like Git, running against something that is highly duplicative and redundant like TFS, I wander what hoops TFS is forced to jump through to make it appear as clean, fast, or simple as Git?

Justin - When you say share, do you mean just simply taking a repo or a bit of code and sharing it publicly with another developer?  ....or share in some other way?

-Adron

[Justin Collum]

I'm talking about SVN externals: http://svnbook.red-bean.com/en/1.0/ch07s03.html. 

Last place I worked that was serious about SVN used externals to pull in 'library' code via tags. Uhh, I can explain that more if needed. 

[John Weldon]

git-tfs doesn't try to make TFS look or act like git.  What it does is simplify the bridge between a local git repository (that can be cloned, etc. as normal), and a TFS repository.

So, I do my day-to-day work in the git repo; branching, merging, committing, rolling back, etc.  When I'm ready to commit to TFS, I use the git-tfs bridge to shelve or commit the changes to TFS.

So far I've done all the 'bridge' work in the master git branch, and any git changesets I want in TFS get merged to master... I suspect that's just result of how I work, and maybe git-tfs has more sophisticated branching patterns available.

--
John Weldon

On Wed, Nov 9, 2011 at 12:24 PM, Adron Hall <adro...@gmail.com> wrote:

[Adron Hall]

Ah I see. If one does branch per feature though, which is a really easy capability in Git, it seems going to Subversion or TFS could be cumbersome. But after thinking about it, I'd bet the history on Subversion or TFS just gets flattened and smashed to a single checkin, especially since neither system has any concept of a remote repository (i.e. client repo in a distributed system).

In most cases, I'm a fan of the way you're doing it.  With teams around 2-5 people sticking to branch seems to make sense. Some would even argue that teams should always stay on master, such as Martin Fowler, but it seems to work really well for some groups to do a branch per feature, keeping things segmented a bit more.

Personally, I'd love to see really functional teams working in either style, and just watch how they go about their approach.  Right now the team I'm on generally just sticks to master, and it works well, but I've been tempted to try out branch per feature, in spite of Fowler's dislike of it.  :)

-Adron

[Justin Collum]

I was surprised to hear that Martin F doesn't like branch-per-feature. So I read the article: http://martinfowler.com/bliki/FeatureBranch.html. Yep, he doesn't like it so much. The thing I don't get is this: what if I'm making a change to the homepage that has a different image that is meant to go live on a specific date (company name change). I should make that change part of the CI? Don't see that working. Sure I could do that, but then anyone who wanted to make a bug fix and deploy it would have to work around my changes.

I've seen branch per feature merge pain in action though -- Fowler has a point about it. 

But there is good news in his article: Promiscuous Integration. On top of being kinda funny it actually makes sense: feature branches merge to each other all the time (but not the trunk) and then merge to the trunk when each branch has run its course. Makes sense to me and DVCS makes this pretty easy to do.  

[Christopher Wright]

There's also the shelveset feature in TFS that's nice for people to store current modifications w/o checking in.  Say you were working on enhancement B when suddenly you get sidetracked to fix a bug in release A (this hardly ever happens to devs, right?)  You can shelve the current code and then reload from a different source. An added bonus is in TFS 2010 you can also share shelvesets with other devs.

 

I really need to look in to this "Promiscuous Integration"... but how would I explain it to my wife?

--

Thanks,

 

Chris

[Justin Collum]

Answering my own question here, but I've not found a real "best practice" for sharing code in TFS. I did find these: 

http://blogs.msdn.com/b/jmeier/archive/2007/03/17/code-sharing-in-team-foundation-server.aspx

http://stackoverflow.com/questions/2872032/share-code-between-projects-in-tfs-2010

http://stackoverflow.com/questions/3385282/best-practice-to-share-projects-between-solution-trees-msvs-2008-msvs-2010

http://stackoverflow.com/questions/5720661/tfs-2010-branch-across-team-projects-best-practices

In summary: wow it seems complicated and no one can really agree on the best way. This seems very basic and TFS doesn't have a real answer for it? Not good. 

The answer in SVN (and its DVCS relatives) seems to be "pull in an external repo". The names change but the concept is the same.