Working With Team System Source Control
I got a chance to work a while with Team System (I'm heavily into Subversion) and I had a hard time working with it. It is not that it is not good, it has some very nice features (the diff tool is awesome, for instance), but I do not like the way it was setup (which is the default, as far as I know).
Exclusive checkouts are a pain in the ass to work with, even beyond locking files, just the idea that every time I try to edit a page (or something tries to edit a page, like a refactoring) it needs to be checked out from the repository and the IDE is frozen in the mean time (can be seconds to half a minute).
Working with integrated source control in the IDE is not my cup of tea. I don't care about source control when I am developing. The only use I have for it is to revert stuff or check it in (and rarely do comparisons) . Those things are best done from outside the IDE, since it forces me to think clearly about what I am doing.
I have seen the people working there edit something and immediately check it in. Often without so much as a check-in comment. It is encouraged, since otherwise they are stepping on each other toes all the time. "Joe, can you release Blah.cs for me?" are common. They do not think in terms of a change set that add some feature to the application.
I know that Team System is a lot more than just a source control (and I'm actually liking the other features very much. Integrated bug tracking in the IDE is cool[1], to mention one in particular). And yes, I know that there are (free) tools that allows workflow similar to the one in Subversion.
[1] No, I don't have to be consistent. Integrated source control is bad. Integrated bug tracking is good. Why? Because.
Comments
Comment preview