TFS 2008 Get Latest Changes checks out project

Hi Russell,



I am not sure why this happens. Most probably, the problem is specific to your test project. Could you please check whether the same problem occurs with a new project?



If the problem is project-specific indeed, could you please send me your project? You can contact us directly using the Contact Support form.

There are times that I've noticed that, even if nothing has changed in a project, the MDS file gets updated between running the automation or between two different machines. 



So, it MAY be possible that, while TECHNICALLY the MDS file has not changed, there are those minor differences between machines, project runs, etc, that would update a project causing the version on your hard-drive to be out of sync with your version in TFS.



One way that the MDS file changes between runs has to do with the use of Project variables.  If you're creating and destroying temporary variables during the course of a test run or updating values in variables during that test run, it is possible that the MDS file will be different, prompting the "check out" message.

The MDS file is being changed by other users, but it's not specifically project variables.



Here is the scenario that seems to trigger checking out the project file.



User 1 has the current latest copy

User 2 has the current latest copy

User 1 checks out the project and modifies something (ie, adds a script, etc...)

User 1 checks in the changes

User 1 Selects Get Latest Changes.  Since nothing is changed there is no dialog asking the user to check out the project.

User 2 Selects Get Latest Changes.  TC indicates that the MDS file was modified outside of test complete and gives you the choice to reload it.

User 2 Selects Yes to the reload prompt.  TC indicates that this action requires it to be checked out.



I am not sure why TC requires it to be checked out to reload it when getting all the latest changes.

It looks like it's object map data that is changing in the MDS file.  I am not sure why object map data is being persisted in the project file or if it can be disabled.

Related to this, we (I work with Russell) have also seen files end up in conflict even though exclusive check-out should have been used.



Example case appears similar to this, though the specifics are not certain:

1. Client 1 and Client 2 are both up to date.


2. Client 1 adds a new keyword test, checking out the keyword tests file and  the project file.


3. Client 2 checks out the file for a different keyword test.


4. Client 1 goes to check in their files; a message is displayed showing the version on the server has changed and a conflict exists for the project file.

There is a change corresponding to the addition of the keyword test on the local file of Client 1, and between the local file and server file a large section of what looks like object mapping info is different.

Object Mapping is a property of the specific project because, from one project to another, you may have different object mapping requirements.  I've seen the behavior you've described where it appears the object mapping is changing when it actually isn't.  I think this is simply a matter of how the project loads on different machines and then, when you save it, that it saves the object mapping in different orders and such.



As for the conflicts for keyword tests, when you add a new file to a project (and adding a keyword test as well as a script unit does this), there's a "Files" section in the MDS file that gets updated.  So, everytime you add a new item, that file gets updated.



Now, as a general rule of thumb, if no actual changes were made to specific project level items (such as test items, object mappings, project properties, "persisted" project variables, etc), when my source control app notes a difference between server copy and local copy, I usually just ignore it and overwrite.  The "files" section will update next time the project loads and the object mapping, as mentioned above, is simply a matter of order.



What you may be experiencing with TFS may be a quirk of that source control system... I can't say for sure, but your MDS file scenarios are an annoyance, but one that can be easily ignored just by telling TFS to download and over-write.

Hi all,



It seems that the problem discussed in this thread is a known one. It will be fixed in one of the future versions of the tool. In the meantime, you can use a workaround suggested by Robert.