As part of a maintenance, I was about to Lock several now-obsolete TeamProjects, by right-clicking on each one's root in Source Control Explorer ($/TeamProject) and selecting "Lock..".Once I was done, I tried to commit these changes, which was denied with the following message:
By searching around I bumped into the following statement, made as part of this discussion:
Locks are applied such that the user who places the lock can
checkin/checkout files but noone else can until the lock is released.
So as a more valid test you will need another user to attempt a
check-in of a locked file - ie not you because you put the lock on.
If this statement stands, using 'Lock' was all together not what I should have gone for. What I actually need is to close down older TeamProjects so that no checkouts can occur anymore. How do I do that?(I suppose I could include in my changeset a misc code change, but I 'd go for something like this only if there were no other options available)
As I understand selecting Lock allows you to check out the file in isolation. But doing so will show the project in pending changes window. And i guess this is not what you want.
Team Project Collections can be stopped from the TFS Administration console, however this functionality is not available for individual team Projects, you can vote for this feature here ... http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2485699-make-it-possible-to-disable-team-project
You could right click the team project and select security, change the permissions for the users to read only so they have no check in permissions.
HTH
Related
I work both from the office and at home, using separate computers. Currently, to be able to continue coding from home, I need to check in all my code before leaving the office. Is there any way of making my workspace work completely online, so that I can continue my work from home without checking-in anything when I'm leaving the office?
I'm currently trying a trick; mapping my workspace on a shared folder (network drive) which I can also access from home via VPN too. But it's taking too long to even download the latest version of the project. Even if this works, I don't think it will be an efficient way because of network speed limitations.
Is there any solution for multiple computers, one user and one workspace?
Assuming that you are using TFVC rather than Git for source control in TFS, then you can shelve your changes rather than checking them in.
Got to the Pending changes area of Team Explorer and click on the shelve drop down.
You now have a couple of options. You must add a name then you can select
preserve pending change locally. This allows you to keep your
changes in the machine you're currently working on.
Evaluate policies and notes. This is only necessary of you have check in
policies set up and it can be ignored if you just want to store your
changes as they are not complete and applying policies at this time
might be inappropriate
Once you have done this then hit shelve. You changes are now stored on the server. When you get to your other machine go in to "Pending Changes" and select the Actions drop down and select "Find Shelevesets"
This will present a list of shelvesets committed by you. You can search for shelvesets by other users but in this case the most recent shelveset created by you should be at the top of the list.
Right click on the appropriate shelveset and select "unshelve". You should now be able to continue working where you left off.
We are trying to follow the branching strategy from the TFS Branching Guide and have reached the point where we have made a branch representing a release, which should now be made read-only.
In the Properties|Security tab for the branch, it presents six user groups each with 10 permissions other than Read. Do I have to go through and click Deny on 60 check boxes, or is there a better way to make this branch read-only?
Right-click the branch in the Source Control Explorer, and select the Lock... option
EDIT:
This seems to get missed a lot when people are finding this so I'll make it more obvious.
Locks appear as a "pending change" for the person who locked the item. As long as the lock is in effect, it will appear as a pending change. When a commit is made of that pending change, the lock is released. While the lock is in effect, the locked branch is effectively read-only, since (to simplify) the locker is the only user who can make commits. The act of committing is what releases any locks on the branch.
h/t #AakashM for pointing that out in the comments
As a quick-n-dirty, you could Lock it for Check Out (although the locker would have to remember to keep the lock in their pending changes forever... which makes me think there's a better way)
To answer the 2nd part of the question -- removing or denying the Read permission effectively denies everything else.
As is mentioned above locking is not a very nice strategy. The correct way of handling this is setting permissions.
You can effectively make files readonly. Users trying to modify the files will get a message 'checkout denied'
https://msdn.microsoft.com/en-us/library/ms252587.aspx#project_level
In VS2013: Team Explorer -> Settings -> Security/Version Control
Deny Check In for domain\domain users
If you have inheritance set to 'On', the best way I've found is to:
'Deny' all permissions except 'Read' to the 'Reader' group, and
Add all other groups (except Project Administrators) to the 'Reader' group.
Then, all groups within the Reader group will inherit the 'Deny' permissions and not be able to do anything but read.
Is there a way to deactivate a project in TFS? (not delete, just deactivate so nobody can checkout or checkin)
This is more of a precaution rather than a hard enforcement. We have a project that was branched but was recently merged to a trunk. This project is no longer in use and I don't want anyone to accidentally use it by checking in/out any of its content. It will eventually be deleted when we have tested the merge completely
In Team Explorer, right click on the project and bring up Team Project Settings -> Group Membership. Go through each group, click Properties, and remove all users and groups from each group. This should prevent anyone who doesn't have a TFS administrator role from being able to check the code out. It may even prevent TFS administrators from being able to check it out without first adding themselves back to the correct project group.
I think this will work, but you should try it as I've never actually done it.
If you still want the project to be available, somebody could just put a lock on the project to prevent check-ins and check-outs. It will remained locked by the user who locks it until either the user unlocks it or their workspace is deleted. An admin can also unlock it using tf.exe.
You can lock a project, branch, folder, or file by right clicking on it and selecting the Lock option from the context menu (note: what you are locking has to exist physically on your drive). This page describes the various types of locks you can place on an item.
For work, I wrote a plug-in to automatically place a check-out lock on production branches once certain criteria are met. The lock is held by the account running the TFS services (in our case, Network Service). Nobody can check-out or check-in files in these branches until somebody uses tf.exe to unlock the branch.
I have a very strange situation.... After migrating from StarTeam to TFS (using TimlyMigration == awesome) there is one oddity.
When I look at any given file in the Source Control view, I see all the history that was migrated. However if anybody else on the project looks at the file, the don't see the history. it sounds like a permissions issue, but even if I change their group membership adding them to project administrators they still don't get the history.
So I'm wondering if there is perhaps a problem with the resposity, and if there is an internal consistency checker for TFS that I could be running.
Does the history include any renames/moves? TFS permissions are based on paths, so if people don't have rights to the "old" path then they won't see the history entries before the move.
One other thing to look into is the permissions in the source control (assuming you have given permissions to the project).
In the Source Control Explorer right click on the project and select properties. Then select the security tab. Users should not need to be added to this, but I have had to do it in some cases.
Vaccano
If I've created a label in TFS, assigning it to several files, my coworkers cannot change the versions of files (nor add other files) to that label. We get this error:
TF14077: The owner of a label cannot be changed.
Researching the problem, I found this article, which states:
It is possible that a user could be
allowed to manipulate a shared label
in the development folder but only
manipulate labels that they own in a
production folder.
(emphasis mine)
Try as I might, I can't find any reference to "shared labels". So far as I can see, a label must have an owner.
FWIW, what I'm trying to do is employ a "floating" label so that developers can indicate that their code is ready to become part of the build by tagging it with a particular label. Then the build process would just need to get everything having that label, and automatically get the most recent stuff that's actually ready to be built, ignoring both past versions as well as newer stuff that's not ready for prime time.
Update:
I figure if I can't make a truly shared label, I can at least give users the right to edit labels created by their coworkers. This is pretty explicitly supported. Regular Contributor users don't have this right, but according to MSDN (see article Team Foundation Server Permissions, under Source Control Permissions), it can be granted by way of the LabelOther permission:
Source control permissions are
specific to source code files and
folders. You can set these permissions
by right-clicking the folder or file
in Source Control Explorer, clicking
Properties, and on the Security tab,
selecting the user or group for which
you want to change permissions, and
then editing the permissions listed in
Permissions. You can set these
permissions by using the tf
command-line utility for source
control.
...
Administer labels | tf: LabelOther | Users who have this permission can edit or delete labels created by another user.
So I've assigned that right to the Domain group that contains all the developers, as suggested above. I can verify that it's set using the tf permission command:
tf permission /group:"CORP\Web Team"
and the result is as expected (I also assigned Label, just for fun)
===============================================================================
Server item: $/Test1/TeamBuildTypes (Inherit: Yes)
Identity: CORP\Web Team
Allow:
Deny:
Allow (Inherited): Label, LabelOther
Deny (Inherited):
Yet my test user still is not being allowed to edit a label I created.
Would shelve sets be a better solution for what you are doing? IIRC there is a fairly rich API for working with shelve sets such as committing them as part of a build (or other) process.
I found labels in TFS to be very limited when I used it.
I never was able to make this work with labels. Instead, we devised a whole different process using branching, which I now strongly recommend to anyone reading this.
We set up a branching scheme so that there's a general development branch; from that, each developer has his/her own branch with which they can do what they want, and there's a Production branch.
Developers do their "dirty" work in their private branch without fear of accidentally releasing stuff, or even interfering with their coworkers.
When they've got something ready to integrate they merge the changes into the development branch. We do continuous builds there, and test the results.
When an integrated build is fully tested and ready for deployment, the changes are merged to the Production branch. This is built and deployed.
I had said I wanted
what I'm trying to do is employ a
"floating" label so that developers
can indicate that their code is ready
to become part of the build by tagging
it with a particular label.
The scheme that I outlined above fully achieves this, and more.