Version Control Model Enhancements in TFS 11
One of the more difficult things for developers with TFS today is the “Workspace”. A workspace is a mapping of code out of a TFS server onto your hard drive and defines all of the rules of how your local operations on those files relate to what is on the server. We’ve heard feedback since 2005 that developers would like some improvements in this space and we’ve made some significant leaps in TFS 11. Some of the more common issues we’ve heard include:
- Workspaces are a new concept that I’m forced to understand before I even get started. The creation experience is unintuitive and takes me a while to get it right.
- Why do I have all of these read-only files on my disk and why do I have to check them out? It makes it a pain if I’m using any tool other than VS (or something with explicit TFS integration). Subversion doesn’t make me do that. I just edit my files and checkin when I’m ready.
- TFS doesn’t work very well offline. Sometimes I get long pauses before it recognizes I’m offline. I have to attrib the read-only files and then do a TFS online operation to sync them back up. And I pretty much can’t do any TFS operation while I’m offline.
- Hey, how come when I do “Get latest” it says I’m up to date when I know I’m not?
A little background before I talk about the improvements we are making. When we designed TFS 2005, one of our design goals was to build a system that we could use for developing Visual Studio. VS is a VERY large code base. Last I checked, each branch was around 5 million files and I suspect it’s a good bit larger than that now. Your average developer needs 100,000 to 200,000 of those files to do their work. Further, developers are scattered around the globe, sometimes over relatively poor connections (when we started in NC, our effective bandwidth was about 300 Kbps :)). In order to manage this efficiently we chose a design where the vast majority of information (including information about your local workspace) was stored on the server. This meant that operations like Get or Merge, etc. could run entirely within the context of the server and only send to the client the few bits of information that the client needed. It scales incredibly well and allows us to support incredibly large teams and code bases. Not everyone needs that, of course. Further, using these “server workspaces” requires you to adopt a certain work style. For instance, you can’t just delete a file from your hard drive and expect the server to know that you need it the next time you do a get. You need to tell the server you deleted it. The server assumes it knows the state of your client and requires that you notify it of changes. It scales really well, but people who are used to just making changes locally and then expecting TFS to understand them were very confused. To address this, in TFS 11, we are adding a new type of workspace we call “Local workspaces”. You can still use server workspaces if you want to (in fact, we probably will still for most of our developers because of the code base size) but local workspaces will be the default. In local workspaces TFS assumes that your client is “the master” and TFS needs to understand the changes that you make there and “do the right thing”. In configuration management parlance, it’s called Modify-Merge-Commit style version control – or some might think of it as “the Subversion style”. In local workspaces, files are not read-only. You can edit them at will. They are automatically detected as “checked out” when you edit them. If you create new files, TFS will detect them and enable you to add them to your project. If you delete them locally, TFS will notice and give you the option of either deleting them from TFS or restoring the local copy from the server. Etc. Etc. One of the implications is that you no longer need to use a tool with version control integration for the right thing to happen (because the file system is the master) – so you can use Notepad or any other tool and TFS will work the way you’d expect. The local copy is the master and TFS tries to just “do the right thing”. Further, as part of this, we’ve dramatically improved the offline scenario. First, it’s a lot better because the local file system is the master and you don’t need TFS to check anything out. Second, we’ve added support to keep a copy of the file that you got, enabling us to support some operations offline, like diff – so you can see what changes you’ve made and undo – so you can revert your changes if you decide you want to start over. Third, we’ve added a local notion of pending changes so you can still do tf status (and see the status in VS) while off line and see all the files that you’ve edited (even though you never told TFS you were editing them). And if you want to tf delete, tf add or tf rename to explicitly tell TFS about those kinds of changes, you can do that too while you are offline. When you return online, everything just automatically syncs up and it was like you were never offline. I’m certain that about this time, I bunch of people are asking “but, did you implement DVCS”. The answer is no, not yet. You still can’t checkin while you are offline. And you can’t do history or branch merges, etc. Certain operations do still require you to be online. You won’t get big long hangs – but rather nice error messages that tell you you need to be online. DVCS is definitely in our future and this is a step in that direction but there’s another step yet to take. **UPDATE** Ack! I forgot to mention a couple of important things. First we are working to make sure that, on Windows our Eclipse client, VS client, command lines, etc all use the same local workspace data so that they are shared no matter which client you are using. Second, I’ve already gotten a question about exclusion lists and I meant to mention them. We do support them though I’m not sure what we have right now is the simplest/best thing. We’ll be looking more at that. If you watch the video closely, you’ll see a link for it at the bottom of the dialog for managing detected changes. Lastly, once you get your hands on the bits, I’m interested in your feedback on how we handle detected changes. We’re debating how conservative vs automatic we want to be.
Checkout this video to see local workspaces in action. Special thanks to Matt Mitrik for putting the video together for me.
Brian
Light
Dark
0 comments