So I'd like to respond to Urig on his latest post about the Get Latest on Check out. The reason why there isn't a get latest on check is quite simple actually. Let's look at VSS vs. TFS in the lifecycle of a change and see how both fare. Let's start with VSS
VSS
1. First thing in the morning, User does a get latest on all the files in the project and compiles to make sure the build is not broken.
2. User does a check-out on the file he wants to work with (and get's the latest of that one file).
3. User keeps working and in the afternoon checks-out a new file (and get's the latest of that one file).
- Where are we know, well user as all the files as of this morning files from this morning + 2 files (newer if they were modified by others during the day). What does that mean? Well if the 2 files he checked out during the day where modified by others and those files depend on other files well he doesn't have those other dependency, only the 2 files the checked-out did the get latest operation.
This causes "working folders" to be out of sync unless you do a get latest all the time on all the files (and ask it to keep your local changed or checked-out copy alone). Now lets look at TFS
TFS
1. Fist thing in the morning, User does a get latest on all the files in the project and compiles to make sure the build is not broken.
2. User does a check-out on the file he wants to work with (and does not get the latest version of it, only a RW version)
3. User keeps working and in the afternoon checks-out a new file (and does not get the latest version of it only a RW version)
- Where are we now, well we are in a much better place that VSS, now our "workspace" is in the same state as of the morning + we have only our changes to deal with (not others changes that might have been brought down by a 'get latest').
Now lets look at the check-in experience,
VSS
1. User now has made his changes and wants to check-in, first he does a get latest and makes sure his file is not overwritten with the latest version controlled one.
2. Build (and run test, etc)
3. If step 2 succeeds, he checks in (One file at a time in sequence, this can cause a whole lot of pain which I'll discuss after).
- So this is pretty simple (as long as you don't have problem or overwrite your changes).
TFS
1. User now has make his change and is ready to check-in, first he does a get latest. This is where the rubber hits the road in TFS, all files that where changed (not be the user) come down, all files changed only by the user are not touched, all file modified by the user and others will need to be merged. Now you might say, OMG merging that's bad it never worked in VSS. Well it works great in TFS and that way multiple people can work on a file and not have to wait for the exclusive lock (in VSS) to be released in order to do their change.
2. Build (and run test, etc)
3. If step 2 succeeds, he checks in (as an atomic operation all files go in or none)
- Now this is in my opinion a much better approach since it lets people work efficiently and you deal with merging and conflicts only once when you are ready to check-in. Also in VSS since the check-in is not atomic, if you loose the network, or the operation fails for some reason in the middle of the check-in then other will have half your changes when they are getting latest, or if someone is doing a get latest as you are checking-in they only get a partial latest. In TFS, since it's an atomic operation, it's all in or nothing. So when people do a get latest they get the whole latest.
I hope this explains a bit of the mechanisms and why it's working this way. I may be changed in the next release, but they will probably do a "get latest of all files in the workspace" on check-out (not just that one file) so that the whole workspace is in sync but I speculate.
Cheers,
ET
Technorati tags:
vsts