Team Development with Visual Studio Team Foundation Server

1. The server determines which files are out of date based on the fact that it knows
which versions are on your disk.
2. The server then tells the client what it needs to do to update its workspace.
3. The client downloads, moves, and deletes files as necessary and then notifies the
server of which operations it accomplished.
A get operation does not mark any files for editing and by default will not overwrite any
files you have checked out for editing.
Additional Resources
• For more information about the get command, see “Get Command” at
http://msdn2.microsoft.com/pt-br/library/fx7sdeyf(VS.80).aspx
What is the difference between shared and exclusive checkout?
Team Foundation Server source control supports both shared and exclusive checkouts.
With an exclusive checkout, nobody else can check out a file until you check it back into
source control. This can lead to bottlenecks in the development process.
By default, TFS also enables multiple users to check out the same source-controlled item
concurrently. This is referred to as shared checkout. With this model, multiple developers
can be working on copies of the same source file in their own workspaces. Team
Foundation Server knows which version is in a given developer’s workspace, and that
developer must resolve conflicts prior to check-in.
In most collaborative development environments, it is unlikely that that you will make a
change in your workspace that conflicts with a pending change in another user’s
workspace, or vice versa. A great majority of the workspace conflicts that do occur are
resolved automatically by TFS. For conflicts that cannot be resolved automatically, you
can use the resolve command to safely decide which change (yours or someone else’s)
you want to keep.
Additional Resources
• For more information about locks, see “How to: Lock and Unlock Folders or Files” at
http://msdn2.microsoft.com/en-us/library/ms181420(VS.80).aspx
When should I use the lock command?
Use the lock command to prevent other developers from checking out or checking in
their changes until you unlock the file on which they are working. You should only lock a
file if you are concerned that there will be a conflict resulting in a complicated manual
merge operation. Because most conflicts can be resolved automatically, you should use
the lock command sparingly, if at all.