With Team Explorer Everywhere you have the ability to use TFS from the command line on any Unix/Linux system. One of the features of the Unix/Linux file system is that you can use so called symbolic links. These are files that more or less work the same as a shortcut, they point to another location on the file system where you can find the actual file. You could also call it a moniker.
This type of file is often used to share a common set of files from another location in the file tree on different other locations of the file system. It is a way to handle dependencies e.g.
Lets assume you have such a system, and you want to place it under Team Foundation Server Version control, how can you make this work?
Welcome in the wonders of .tpattribute files.
.tpattribute files get their name from the early days of Team explorer everywhere, the company where this was first build. Team Prise. a .tpattributes file is just a text file that can contain the definition of a symbolic link. this definition is then used on a get operation in that workspace to be applied to a certain file so it becomes a symbolic link.
In the past (before Team Explorer Everywhere 2012) you also used these files to set for a set of files e.g. the execute bit on a get operation.
the contents of the .tpattributes file is described very shortly here: http://msdn.microsoft.com/en-us/library/gg413272(v=vs.100).aspx
Lets use an example to clarify its usage:
Lets assume we have the following symbolic link we want in our workspace:
It points to:
site_config -> ../client/bin/site_config
For this to happen on a TF get command, we need the .tpattributes file to contain the following information:
When we have created this file we check it in. But that is not all to make it work! In order to actually make the magic happen we also need a file in version control as the placeholder for the symbolic link file. Easy way to do this is by deleting the symbolic link file and then recreate a new 0 bytes file with the touch command.
then we check in the .tpattributes file and the 0 bytes placedholder file, site_config in our example case.
Now to see the magic happen, we can set up a new directory and workspace mapping and then execute a get operation on that folder. What happens is that it will get the .tpattributes file and when that is on local disk, will be used by the tfs client to apply the symbolic link to the file site_config.
So the moment you get the site_config file, team explorer will convert it to the symbolic link. this can be easily verified by executing a ls –all command and then you can see it point to another file.
This symbolic link will not be set up when the file it points to is not available.
Another thing to note is that in the past the .tpattributes file was also used to set the execute bit on files. you could do this by starting the file with e.g. the following regular expression:
This then resulted in all files in that directory to get the execute bit applied.
Now I have experienced that sometimes when your file starts with this syntax to set the execute bit on a certain set of files, sometimes the symbolic link is not created. the solution is that you remove this part from the file. the reason that can be done is that TFS will keep track of the the execute bit status on a file and when executing an add it will add this information with the file in TFS. when you get the file on a Unix/Linux system, then TFS will restore the execute bit without the need for the .tpattributes file.
Hope this helps, I can tell you it took me quite a while to get this figured out.
CTO at Xpirit, Microsoft Regional Director, Visual studio ALM MVP, Speaker, Pluralsight Author and IT Architect Consultant