Editing a project that is versioned in Team Foundation Server is very straightforward. Unlike local multi-user editing and some other version control systems, you can edit anything in the project without any restrictions at any time. No files or other components are ever locked for you. Also, you do not have to have a connection to TFS to edit your local working copy. This means that you can always work on your project. For example, you can work on it at home, or when you are flying across the Atlantic in a plane.
TFS never forgets. If you delete or rename a topic (by changing its Topic ID), TFS retains the former version of the topic file with its original name in its repository. Not only that, it also blocks the original name for reuse permanently, even though no topic with that name exists in your project any more. If you then try to use that Topic ID again for a topic, you will no longer be able to synchronize that topic with the TFS repository. If this happens with multiple topics your users will have working copies that are increasingly different from the main copy in the repository.
Because of this, you need to be extremely careful when deleting and changing the IDs of topics in your projects when they are versioned in TFS. Ideally, you need to make a note of all IDs that you have changed, because the old versions should never be used again in that project.
You need to synchronize your work with the master copy on the server. Synchronizing simultaneously gets new material from the server (download) and adds your edits to the server version (upload).
If you have edited the same text as someone else, there will be a conflict and you will have to decide which version is going to be kept, yours or theirs. This won't happen if you edit different parts of the same topic that don't conflict with each other; those will be merged silently. You will only get conflicts if you both edit exactly the same text, so that there are different versions of it.
This is all less daunting than it may sound at first. In most cases all team members' work will be merged into the master version without problems. The easiest way to avoid conflicts is to have clear guidelines in your team defining who is responsible for which sections of your project.
If you have access to the TFS server, always synchronize with the master copy before you start working. And always synchronize again after you have finished. However, don't synchronize until you are finished! Otherwise other team members could get confused by seeing your half-finished edits and might even try to correct them!
You open TFS working copy in exactly the same way as any other project. The only difference you will notice is the version control overlay icons in the table of contents, which show the current synchronization status of your topics.
Green icons mean your changes have been synched – but there may still be updates on the server!
When all the icons are green it means that all your changes in your local working copy have been synchronized with the TFS version. However, if you are starting work it is quite possible that other authors have made changes to the master project in the meantime. So if you have access to the server, you should always select Synchronize TFS in the Project tab to get all the latest updates before you start work. (See further below in this topic for information on the Refresh Project tool in TFS versioned projects.)
If all the icons are green when you start synchronizing they will stay green afterward, because everything will still be up to date.
Editing a TFS versioned project is exactly the same as editing a normal project. The only difference you will see is that the SVN overlay icons in the TOC will change as you edit and add topics.
At the end of your editing session you should synchronize your work with the TFS server again so that the other authors in the team have access to your changes. Of course, this is only possible if you have access to the server, but you should always do it as soon as you can.
When you synchronize your project with the repository on the server, the sysetm checks whether there are any conflicts between your changes and the master version. If there are, the diffing editor will be displayed so that you can resolve the conflicts.
The topic highlighted in red contains a conflicts that the has found. This means that two authors have changed exactly the same text in different ways in those topics or other files.
Right-click on the conflicted file to display the conflict context menu:
Resolving the conflict quickly with the context menu:
If you are sure about whose changes are correct, you can resolve the conflict directly with this menu:
•Revert will eliminate all your changes and return to the original version from the repository.
•Resolve using Theirs replaces the conflicted text with the version from the repository. Any other changes you have made in the topic will be preserved.
•Resolve using Mine replaces the conflicted text in the repository with your version. Any unconflicted changes made by other authors will be preserved.
Checking and resolving individual conflicts with the diffing editor:
Usually, however, you will want to check the conflict with the diffing editor. To do this select Edit Conflicts, which displays the editor:
The editor is set up to show the version in the repository on the right (Their File) and your version on the on left (My File).
Important: You can only copy from right to left!
1.Scroll through the file and compare the server versions (right) of each conflict with your version (left).
2.Click the yellow arrow to the left of the server version conflict to overwrite your local copy with the server version for that conflict.
3.If you want to keep your version of a conflict, do nothing. It will overwrite the server version in the final step when you re-synchronize.
4.When you have checked all the conflicts click on the green Accept left side button at the top left to confirm that your modified local version is the version that should now be used to resolve all the conflicts.
5.Close the diffing editor. The status of the file will be changed from "Conflicted" to "Modified".
6.Repeat for all conflicted files. You can then synchronize again and the synchronization will go through without conflicts.
•Lines containing conflicts are highlighted in pink. The actual conflicts are shown in red. If you click on a conflict in the right box you will see a small yellow arrow in the left margin. Clicking on this arrow copies the server version of the current conflict to the left, overwriting your version.
•If there are multiple conflicts you can step through them with the Up/Down arrows in the toolbar.
•You can copy ALL the server versions of the conflicts to the left side with the yellow Left arrow in the toolbar.
•When you are satisfied with your changes click on Accept left side to complete the conflict resolution.
The Refresh Project tool next to the Synchronize SVN tool is not directly relevant for SVN versioned projects:
This tool does not have any effect on synchronization with Team Foundation Server. It is only relevant if multiple users are editing the SAME project using Help+Manual's normal multi-user editing mode. Then the Refresh Project tool updates the changes made by other users editing the same project.