posted by gregbeech(76) 2 years, 8 months ago 0

This is mostly just a rant from somebody who doesn't understand how TFS works. May as well just have called it "TFS isn't Subversion and I don't like it because of that". It doesn't even touch on the points that are important in a source control system such as branching/merging (excellent) change tracking (excellent, even for renamed files etc) and reliability (we've been using it for years with no major issues). Yes, there are some annoyances, and it's by no means perfect, but this article doesn't really cut it.

Reply

posted by josephf(235) 2 years, 8 months ago 0

gregbeech -- I would love to know how you handle some of my annoyances. Specifically read-only files, identical files, code reviews, integrating with non-.NET developers, and working offline. The rest of the problems I can live with.

I didn't mention branching/merging, change tracking, and reliability because TFS doesn't really do it better or worse than other version control systems.

And, yes I completely agree that TFS is not SVN but I can't think of anything TFS does that SVN doesn't.

Reply

posted by belorion(5) 2 years, 8 months ago 0

@gregbeech - I would be interested in how you handle some of those points pointed out in the article. (I've never used TFS, and am simply curious). Maybe post them as comments to the blog post?

Reply

posted by JShimty(15) 2 years, 8 months ago 0

FYI: Things TFS does that SVN doesn't: Shelving ... But yea, that's about it.

Reply

posted by Davbis93(17) 2 years, 8 months ago 0

I dissagree with some of your points.

Identical Files - I'm not sure what you're talking about: A file won't get cehcked-in if it doesn't contain any changes.

Code reviews/update - You can easily achieve this, by right-clickinmg in a code-window, and going source-control/annotate.

Project file modification - This would be a complete pain in SVN too (I'm pretty sure) - you could always have two project files - one for each server. (this would need maintaining, in the case of changes to the solution structure)

Everything needs to be in the solution - Wrong. You can add add-hoc files from source control explorer, by clicking the "add files" button.

I've used both SVN and TFS quite extensivly - and find that in general, TFS & VS are wonderful tools - although not without their faults. I find during day-to day usage of SNV - that my source-tree breaks for no-reason all the time. I get "unresolved conflicts" for no reason at all. It constantly tell me to "clean up" - and then the "clean up" crashes my computer.

Both products are imperfect - but at least Microsoft doesen't release updates every 10 minutes, like Tortoise do.

Reply

posted by tallen(130) 2 years, 8 months ago 0

@Davbix93 -- Subversion != Tortoise. Just saying Subversion is fairly stable and there have only been 8 releases this year (1.5.6 to 1.6.5). Tortoise is a third party Windows shell integration tool.

My experience has been Subversion is very stable, coupled with a very stable client its fairly good stuff. I agree with OP that TFS isnt perfect but perhaps with a more intuitive client some of the perceived short-comings would be better understood.

Reply

posted by sceptical(0) 2 years, 8 months ago 0

Davbis93

Here is my take on these issues.

Identical files - Very often TFS/VS.Net have checked out a file for that I have not changed. I think that we he meant by identical files. Files that are in the pending check-in, but hasn't changed. Have seen this in SVN as well, but more rarely.

Everything needs to be in the solution - What he means is that because the file has to be checked out on the server that editing the file in anything but a VS.net solution requires a manual check-out. Very painful if you come from SVN world.

I agree, SVN has it's falts as well, but I don't mind getting new releases often. The new release usually means a bug or two has been fixed and if I ever have a problem with TFS, I might need to wait a year or two to get a new release.
To often or rarely, then I select to often.

The people designing TFS didn't have a laptops, mobile or disconnected workforce in mind when designing TFS. I think that the server needs to know that I'm editing a file is so SourceSafe and is the biggest problem with TFS.

So far I would say that TFS is slightly better at merging, SVN better at branching.

Reply

posted by josephf(235) 2 years, 8 months ago 0

Davbis93

Identical Files - What I mean by this is in the "Pending Changes" window you see all files checked out even if they aren't modified. Try going into a file make a change, undo the change. You will see the file in the "Pending Changes" window. If you are using SVN you will not see it.

Code reviews/update - How do I know which files changes?

Project file modification - I'm talking about the path to the TFS repository itself. Open the sln file and look for "Scc*" you'll see all sorts of paths etc.

Everything needs to be in the solution - Sure but that's a big pain unless you go into "Team Explorer" every time to update instead of solution explorer.

I think "tallen" is correct SVN != Tortoise. Although I've been using Tortoise for quite a while and I haven't had problems.

Reply

posted by belorion(5) 2 years, 8 months ago 0

The simple fact that files are read-only until checked out is enough to not use the product, for me. First of all, I'm not always in VS or TS. And I don't care if I'm working on the same file as someone else. Chances are the code will merge just fine. If it doesn't then I need to have a quick 2 min chat with the other user to make sure I can resolve conflicts correctly with their new code. But preventing me from editing the file at all is a complete productivity killer. The only time you might encounter unmergable-changes are binary files - MS Word documents or image files. Heck, even merging MS Word documents has gotten easier - from Tortoise if I look at the changes it loads up word and shows the changes in Words "track changes" format. If unmergable changes in binary files happens frequently, then your team members should most likely be communicating better with each other anyway. Why kill productivity the other 99% of the time just so you can avoid this?

Reply

posted by ccyvas(635) 2 years, 8 months ago 0

+1 for subtlety ;)

Reply

posted by bzbetty(0) 2 years, 8 months ago 0

@belorion, You seem to be talking about exclusive checkouts and not about whether a file is marked as read-only in your local file system. TFS handles multiple people editing files perfectly fine, but also allows you to setup certain file types that can only be checked out to one person at a time (Word files for example). That said why you'd keep word files in your source control repository is beyond me.

Reply

posted by Jemm(9604) 2 years, 8 months ago 0

I've had no problems with any of the mentioned items, but they are dependent on the usage patterns, anyway.

However, source control is just one side of the TFS/Team System, so if it has some flaws it's still a complete ALM-solution that integrates everything together. Granted, it could be faster on some places and easier to install, but it's improving gradually to a better solution. :)

Reply

posted by belorion(5) 2 years, 8 months ago 0

@bzbetty Interesting information, thanks. I'm curious - why mark the files read-only at all then?

Reply

posted by bzbetty(0) 2 years, 7 months ago 0

@belorion, presumably to stop you editing files before checking them out? Admittedly requiring you to check files out can be a bit annoying (especially since other sourcecontrols don't require it) however with the added ability of exclusive checkouts (which are handy on occasion), the ability to see what others are working on (handy in teams with low communication) and potentially even seeing what you had checked out yourself in case of a hardware failure (not really that useful but I have needed to do it in the past) I find it worth the hassle, that said i don't often try edit a file in something that doesn't support TFS checkouts automatically.

What I really want is a list of change comments when I get latest =(

Reply