how limit getting changes for a user in TFS? - tfs

I want to limit a user in TFS.I want he get all of changes in my repository except changes of a special user.how can i do it?
thanks

It's not able to do this in TFS.
We could use permissions to limit access to particular files/folders or branches. However, we could not limit access to someone's changes.
As you know, we store source control changes as changeset or commit.
When you check in your changes, they are stored on the server as a changeset. Changesets contain the history of each item in version control.
You can view a changeset to see what the exact file changes were, discover the owner's comments, find linked work items, and see if any policy warnings were triggered.
In other words, we are not able to mange permission for a special changeset. For example it's not able to forbid a user to see changeset 100, but be able to see changeset 99, changeset 101.
It's also not able to block user which make him unable to view the revision history or get a specific version of a file/folder.

Related

Downloading all Changesets Except one in TFS

Recently, one of the junior developers made a check-in to a large MVC SOA C# application, to both the client and service side, which makes the project unbuildable. Their check-in added spurious dependencies as well as removed required files, with something like 900 files in the project affected.
In order to keep the project moving forward, I was instructed by management to simply obtain the project from the changeset prior to this check-in in TFS and and then apply all changesets after the bad check-in going forward, since we though a release would be urgently needed.
As the weeks have passed, however, this approach is getting untenable. Is there a way to do one of these two things in TFS?
Either
remove a changeset from TFS without removing the changesets that come after it?
or
Automatically get all of the changesets in TFS for a solution except for one specific changeset.
remove a changeset from TFS without removing the changesets that come after it?
According to the document Roll back changesets:
A changeset is a permanent part of the history of your
version-controlled items and cannot be undone or removed. However,
you can roll back the effects of one or more changesets.
So, we could not remove one specify changeset. Just like James said, we could roll back the bad changeset. But it will also remove the changesets that come after it. As workaround, you can check the Changeset details for that specify changeset. Then ask that the junior developers remove his code, then check in the delete changeset.
Automatically get all of the changesets in TFS for a solution except
for one specific changeset.
There is way to find and view a TFS changeset by comment text:
tf history $/ -r | ? { $_.comment -like '*findme*' }
Check the this thread for some more details.
But there is no such out of box method to exclude one specific changeset in the text, we need to write our scripts like, batch, powershell to except it from the text.
Hope this helps.

How do I make small local commits with TFS?

I'm in a company now that forces TFS upon us. I have used Git all my life, and I am struggling to find some features I am used to in TFS. For example, I'd like to make small commits locally and push them up later together. This way I can keep track of my changes and roll back if I ever need to. Is there a way to do this in TFS?
What you're looking for is called "shelvesets" within TFS.
This link explains how to create one:
MSDN on how to create a shelveset
To shelve folders and files from Solution Explorer
In Solution Explorer, right-click, and then click Shelve Pending Changes.
In the Shelve - Source Files dialog box, type the shelveset name (for example, shelvetest) in the Shelveset name box.
The Shelve - Source Files dialog box includes two options:
Preserve pending change locally
By default, this option is selected. When this option is selected, the changes you made to the files or folders in your local workspace are preserved.
Evaluate Policies and check-in notes before shelving
When this option is selected, all check-in policies are evaluated before the shelveset is created. For more information, see Set and Enforce Quality Gates.
In the Comment box, type Testing my shelveset, and then click Shelve.
The files and folders are copied to the version control server and are available for other team members to unshelve.
And this link provides some background about using shelvesets:
MSDN on reasons to use a shelveset
For a variety of reasons, sometimes you need to set aside some or all of your work in progress. Shelvesets are useful when you want to stop work for:
Interruption: You have pending changes that are not ready for check in, but you need to work on a different task.
Collaboration: You have pending changes that are not ready for check in but you need to share them with another team member.
Code Review: You want another team member to perform a code review of your pending changes.
Private Build: Before you check in your changes, you can use your automated build system to build and test your code.
Backup: You have work in progress that you cannot finish now so you want a backup copy that is stored on your server and available to other team members who might need to access it.
Handoff: You have work in progress that you want to hand off to another team member.

How do I associate a review request with multiple changesets in TFS 2012

Our development process works like this: Every 2 weeks the team lead (me) goes in and reviews everyone's changesets to make sure they are up to the coding standards. I would like to use TFS 2012 to help automate this process.
There are 2 problems with this:
There is no way to submit an unsolicited code review. I can live without this if necessary, I guess
There is no way to associate a code review with more than one changeset. This is a deal-breaker
I read one article which said it's possible to link changesets to a work item after the fact and when I open the work item for the request review I do see the Links tab. However, when I click "New" or "Link to...", there is no option to link to a changeset. There is only an option to link to each work item type in the process.
Does anybody know how to do this? Are there any plans to add these features to TFS?
Here's a screenshot:
Unsolicited, no.
You can rightclick a changset in the history screen to request a review post checkin.
And there is a nasty workaround to get what you want to achieve. Check out all files you want to review and request a review. You can then undo your checkout, the shelveset and the review request will remain.
Alternatively you can just go to the source control tab and do a checkout-all on the rootfolder of your solution, request the review, undo your checkout and do the review.
As for linking changesets to a Work Item, this can be done post checkin. Open the work item, go to the links tab and click "Link to..." The dropdown there will have a "Changeset" option. But I don't think this link type is enabled for Code Review Requests, since these use a Shelveset and not a set of changesets as the source for the code to review.
I expect you could use the TFS API to generate a shelveset with all the changes from a specific developer in a given timerange, put these on a shelveset and request a review on that. But no existing feature to do that exists.
Or you might be able to edit the shelveset of associated to the review by creating a new one with the same name.
An alternative approach:
1) at the beginning of the two week cycle, initiate the code review process and note the work item number that is created. Simply request a review from yourself with no code changes at first.
2) Have all your developers associate their check ins for the next 2 weeks with that work item #
3) When you are ready to perform the review, simply open the work item and go through the changesets.
That should accomplish what you want.
Option #3
[I'm assuming here that the changesets that your are trying to associate to a single code review are consecutive, for example 20001:20010]
I "roll[ed] back to a specific changeset" (in my example above
20001). I check it in the changes. The code is now in its original
state.
Then, I "roll[ed] back to a specific changeset" (in my example above
20010) and check it in again. The code is now in its final state.
Finally, I request a review on the latest revision. This review
compares the latest two commits - the ones I created from the
rollback.
As a bonus you can compare specific changesets in the history page. You can use this compare to make sure that the commits above did in fact revert the code to revision 20001 and 20010.
On item #2, I have a standard work around that you might like to combine all changes from many changesets into one shelveset for review. I tried the checkout method mentioned above and ran into issues, partly because my review had 25 files or so and after checking them out, if I refreshed, TFS removed them from pending changes because it TFS's opinion there were no changes.
First, (assuming that your changes are already checked in, and in multiple changesets), have a workspace with the latest files on a disk path such as D:\Latest...
Create a new "local" workspace (called "Review"), map the same project to the slightly different path (say, D:\Review...") get all the files. Go to the history of that project and just before your earliest changeset, right-click and select "Get this version".
At this point, go to the history and rollback any changesets that someone else may have changed in the meantime, if any, that you don't want to be part of the review, unless someone changed a common file. Leave those.
Using beyond compare, compare "D:\Latest..." to "D:\Review...", copy your changes from Latest to Review. Go into the common files and copy only the lines that you want reviewed. When Beyond Compare writes out the changes, TFS will detect the change and put the file you save in your pending changes list for the "Review" workspace. (That's a feature of local workspaces.)
At this point, you just shelve your pending changes from the "Review" workspace, and request a review on that shelveset.

Is there any way to delete or alter file history changes in a Team Foundation Studio repository?

A team member's username/password was inadvertently checked in to a file in source control. While the person will likely have to change their username and password anyway, is there any way to delete this history of the file from TFS?
Ideally, we could just blank out the password within the history. I found where the data is stored in SQL, but the data is hashed, so I can't just edit it directly (I don't think).
Thank you.
Generally speaking, history is mostly immutable, however you can destroy items that were errantly checked in using the tf destroy command. For example:
tf destroy $/Project/Folder/file.txt
will permanently delete all references to that file in history.
(To clarify what I mean by "mostly immutable": aside from being able to destroy historic items, you cannot modify version control history, that is the changes that comprise a changeset. However, some version control metadata can be changed, including changeset comments, work item associations, and check-in notes.)

Migration of source code from one collection to another

I have installed the TFS integration tool and tried to migrate source code from one collection to another on same server. It is working and it copied the code with history to new collection however the history which it is showing is check-in by single user which is mine as I have migrated:
This was the history of one file before migration
This is the history after migration, in this the changeset numbers are changed and the date is also changed. Old Changeset information of number, date and checkin is given in brackets.
If we right click on any changeset and select changeset details than it shows the complete information as shown:
As this migration gives a new changeset number all over previous linking of workitems with changesets will be lost.
Am I doing it right or there is any other way to do it? Can I get the same history as that was in previous collection.
The TFS migration tool is great, but still has some limitations. For example, it is not possible to keep the date of the original checkin and the changesetnumber will not be the same. It is possible to keep the changeset number the same. To achieve this, activate the user mapping feature as described in http://www.felinesoft.com/blog/index.php/2010/11/tfs-to-tfs-migration-between-two-domains/

Resources