Internally in Teamprise, we have been having a lot of discussions about check-in and check-out in Team System and how to explain this concept to our end users. The problem is that the terms are overloaded depending on the source control system that you come from. In Visual Source Safe (VSS) or PVCS, check-out means “give me the latest version of the file and lock it so that no-one else can edit it”. In CVS and subversion, checkout means “get the latest version”. If you are using the source control features in Team System then checkout means “Tell the server I want to edit this file and mark that file as writeable in my file system”, at the same time that you check-out the file you also get an option to lock the file using one of three lock types (none, check-out and check-in).
We have to figure out a way to explain this to the end user, as this is new behaviour to them no matter what source control system they are coming from.
We have had a few users complain about the Teamprise TFS client because when they check-out a file they do not automatically get the latest version, similarly I once saw a good developer stop the work of an entire development division because he did a check-out of the entire source tree in VSS. Previously he’d been familiar with CVS and Subversion and I hadn’t made time to point out the differences before getting him access to the repository.
Team System has the concept of workspaces. The server is aware of your workspace, it knows what local directories you have mapped in that workspace, what versions of files you have in that workspace and what pending changes you have informed the server about. To get the latest version of a file, you must explicitly call Get Latest to download the files. If somebody creates a new version of a file, you will not see it in your local file system until you do a Get Latest again.
When you check out a file, what you are actually saying is “Server, I have am about to edit version 3 of my file.”
Finally, when you check the file in, you take the file from your local workspace and pass it over to the server. This now becomes the latest version of the file.
Now, imagine that you had not done the get latest before you did the check out. When you go to check the file in, the server knows that your changes were based on version 1 of the file so it will warn you that there is a conflicting change and get you to resolve these conflicts before checking in that file.
Why does it not just get the latest version when you do a check-out the file? The problem with that is that if it were to get the latest version then that might introduce new dependencies on files that you have not got yet. Team System plays safe and only gets the file when you tell it to.
In our Eclipse based client, we are currently debating if we should prompt the user when they are checking out the file that is not the latest version to ask them if they want to get the latest version at that time. If we do we’ll probably have a Yes, No remember preference type prompt. Personally, I like the way Team System behaves - I think it helps to encourage small incremental check-ins and only does things when you tell it to. In Eclipse we support the Synchronize view which will give you a picture of what differences exist between your local workspace and the server, that way you can easily see if a check-in that you are about to commit will not cause any problems with the version that now exists in the server.
Like everything, you still need to make sure that the team communicates and people are clear who is working on what. Team System definately provides a very powerful and flexible source control system to the end user - we just need to figure out a consistent viewpoint to present it to the user so that the entire source control system feels transaparent and just behaves as they expect...
Thanks for sharing the information. It is quite helpful.
Idiots, they only delayed the merge process, and make it hardly.
They could make the option when i want to get latest wersion: manualyy or at checkout !
I understand in C++ that they dependency issue can get really hairy. In Java that does not happen nearly as often.
I only want to work on the latest version of the file. Why? Someone else may have already fixed a bug. Why do I want to fix it, send it to the server, be told I need to merge then see someone else made the exact same or very similar fix? Plus my change my hose over some other code that was checked in to some other Java file.
I don't see the worth of this way of doing things as it will just get you broken builds because you are not forced to build and use latest when are are about to make changes that can easily affect more than one file.
I want to be prompted every time to let me know I am not using the latest version.
Thanks for sharing this info!
hejdig.
@Serg&Kevin
The reasons one might not want to always have the latest version is up to every developer. In my current project I normally do not get the latest while my colleague always does; it is all up to taste and where one work (presentation layer, datalayer, vertically, horizontally, common lib, documentation, ...)
@MartinW
> currently debating if we should prompt the user when they are
> checking out the file that is not the latest version to ask them
> if they want to get the latest version at that time.
The best would be to have it configurable. I am very helped by a warning every time I touch a commited file so it gets dirty. This makes me get a feeling for how much I have dirty. I has also several times stopped me from updating the wrong file.
Happy hacking!
/OF