We implemented a custom check in policy, and selected it for one of our TFS project.
If a TFS client does not have the policy installed, TFS will show an error message with the installation instructions. This is all good.
However we have a problem when there is a new version of the check in policy.
It seems like TFS only enforces the policy name and not its version.
So even if I remove the old policy reference and add the new, all clients who already has the old version installed are still allowed to use it.
I would have expect that TFS would not allow to use the old version of the check in policy.
How could we enforce this?
One possible workaround could be to checkin the latest version number as a file to a project which can be accessed by anyone. The check in policy itself would read that file, compare the version with it's own version and generate a PolicyFailure if the version does not match.
Maybe there is an easier/better way?
Finally I decided to use the workaround originally suggested:
"One possible workaround could be to checkin the latest version number as a file to a project which can be accessed by anyone. The check in policy itself would read that file, compare the version with it's own version and generate a PolicyFailure if the version does not match."
Works well.
You could add policy version number to the end of policy name and introduce the updated version as a new policy.
This solution comes with a little management overhead but makes sure the you get the error with every new policy version.
Related
Is there any trick to just get a specific version of just a solution? I have a large number of solutions and support libraries in the source code tree. I would prefer not to have to bring all of them down when I build a sandbox of a specific labelled version. In VS2015, I can open a specific solution, but is there a way to specify the label when I do this?
It is not possible to choose the version of the solution when opening it.
You can however choose to get a specific version of the solution and its projects when getting the source code locally. You can do this by right clicking the solution folder in the Source Control Explorer and selecting Get Specific Version. Here you can select a specific version either by specifying a changeset, label or date.
I think I have a solution with the suggestion from Tore. You can use the File/Source Control/Advanced/Open From Server... to load the latest version of a solution into your sandbox. Once you have the latest, you can use Tore's suggestion of Right Clicking on the solution then Source Control/Get Specific Version... to pull down the labelled version you want to work on. This appears to limit the file structure of the sandbox to just the files you need to build the solution.
Seems to work with the limited number of labelled version I have. Will update this post if I have trouble with more history in the vault.
We are in the process of migrating/upgrading our TFS2010 to TFS2013, new infrastructure.
We are following the step by step upgrade guide.
Regarding workspaces, do the developers need to remove all the local mapping to the old TFS instance before the upgrade? If Yes, we can ask them to remove.
However is there any way to find out whether the developers have removed all their local workspaces from TFSadmin point of view rather than asking the developers to say whether they have removed or not?
Best Regards
However is there any way to find out whether the developers have
removed all their local workspaces from TFSadmin point of view rather
than asking the developers to say whether they have removed or not?
Installing TFS Sidekicks will allow you to see what workspaces exist for a particular User / Machine, it will also allow you to delete workspaces and to remove file locks.
It is not required when doing an upgrade to have developers remove workspaces. After the upgrade Visual Studio will automatically match it all up correctly.
Note: Make sure that you only do this for production. If you are doing a trial migration you MUST change the server ID to prevent VS getting confused!
http://msdn.microsoft.com/en-us/library/vstudio/ee349259(v=vs.110).aspx
Does TFS have a way to indicate that I have gotten an old version of a file?
I have previously used Accurev which will put the old version in your default group. So I'm wondering if TFS shows this information somewhere?
If you look in Source Control Explorer, there is a column called "Latest". It would show Yes, if you have the latest file and No" if you don't have the latest version.
Please be mindful it doesn't scan your file contents to see if you have the latest. For example, if you have manually updated the file in your local drive without using TFS, the latest column will still show the status it was in before.
I got the latest code for my database project. When i check in my stored proc, It simply overwrote the TFS version and it didn't even prompt for any Merges or differences.
Wondering if there are settings that i have to take care?
TFS will only prompt for merges if someone has checked in (modified) the item after your check out. If the item hasn't changed since your check out, your check in will simply put your version in place over the existing version. That is expected behavior.
We used to use SourceSafe, and one thing I liked about it was that when you checked out a file, it automatically got you its latest version.
Now we work with Team System 2005, and it doesn't work that way - you have to "get latest version" before you start working on a file that you've checked out.
Is there a way to configure Team System (2005) to automatically get the latest version when checking out a file?
There's a Visual Studio Add-in for this that someone wrote:
http://blogs.microsoft.co.il/blogs/srlteam/archive/2007/03/24/TFS-GetLatest-version-on-check_2D00_out-Add_2D00_In.aspx
Are you sure you want that?
It means that when you check out a file, it will be out of sync with the rest of your files. Your project may not build or function properly until you update all files.
#Vaibhav: Thanks a lot!
#Jay Bazuzi: I understand what you're saying, but for me it's very important that if a developer is working on a file, it be the lastest version of that file. Otherwise the check in introduces a lot of problems. If for some reason, as a result of the getting latest version, the project doesn't compile, then by all means get the latest version of the whole project. For the way our team works - often check-ins - this is good. If you made changes you want to keep - shelve them.