3 ms·
My experience is limited, but the source control aspect of TFS seems really crude compared to git. Branching is about as hard as an old-school Perforce or CVS r
by sirmarksalot 13y ago
My experience is limited, but the source control aspect of TFS seems really crude compared to git. Branching is about as hard as an old-school Perforce or CVS repository, but without the flexibility in managing your local changes that those systems allow. It only lets you keep one changeset active at a time, which can be hacked around using shelvesets, but not without occasional hiccups (TF Power Tools are often the only way to recover your work after particular kinds of operations).
I've found that every workflow I can come up with is "wrong" in some way, but none of the documentation tells me what the "right" way is. Git may have been in a similar place when it was first released, but nowadays there are plenty of good tutorials that walk you through the way to think about it.
The GUI is clunky and requires lots of clicks to perform routine tasks. For example, to view a file's history, you need to open each changeset individually and diff the file in each one. The command line is no better, and makes heavy use of the "observe something to initialize it" anti-pattern.
The main draw seems to be its integration with issue tracking, unit tests, code reviews and project management. It's trying to be a one-stop shop for everything, but the problem is that each feature has a better stand-alone equivalent. So you either lose the synergy of having one tool for everything, or you sacrifice the features that you really want from your favorite source repository, code review tool, diff utility and bug trackers.
This has become quite a rant, but I'd really like to hear a good explanation for some of these things, or at least somebody to tell me what I'm doing wrong. The worst is when somebody knowingly says "come on, it's not that bad" without actually offering a more functional workflow.