I'm trying to switch from SVN to TFS, and I'm wondering if there's any way to manually set the TFS Changeset ID to match my SVN Revision number. I have a few internal tools that perform some automated tasks based on the SVN revision, and they're all going to stop working if the revision number changes from 2,050 back down to 1.
I'm sure this isn't really the optimal way to handle these internal processes, but it's working for us and we'll probably only be using these tools for the next 12-18 months, so I don't really want to rewrite them. Any ideas would be appreciated.
I doubt that you get to set TFS changeset IDs. However, usually when migrating between source control systems, you use some tool/script that migrates the history, creating checkins that match the original checkins in content (not in IDs though), and that might set the changeset IDs more to your tools' liking.
It's controlled by the in tbl_ChangeSet.ChangeSetId field in the collection DB. It's an hack but you should be able to drop the primary key constraint, assign it with any value, and set back the primary key.
A safer approach would be creating a custom Check-In Note ("SVN Revision") for storing the original revision numbers.
Related
I have a need to get a list of all branches with paths and IsDeleted status. I can do this with the API from a development environment, but I will be unable to use the API in the production environment. A workaround is to query the TFS database for the data I need. I found the branches table (tbl_Branches), but it doesn't have a status column. I am not sure what I need to join on to find the status.
I am looking for the status that is from the property branchObject.Properties.RootItem.IsDeleted if using the API.
Does anyone know what to look at to get the same status for the branch as what the API uses?
Thank you.
The branches are tracked as items. So you need to join "tbl_Version" to get all the versions for the branches. The entries with "DeletionID" > 0 means ther are/were deleted. However, we don't recommend to query TFS Database directly just as Daniel mentioned in the comments. You should avoid this if you have any other workaround.
I wrote a plugin that saves and updates a certain numeric field which is part of the layout of a workitem in the TFS.
The problem is, a lot of updates \ changes are done in the backend on this field, and when someone reviews the history tab of the workitem, they can see a lot of these changes documented, when they have no real added value being documented, and simply clutter the history view.
is there a way to configure the TFS \ save a workitem in the backend and have that change excluded from the history logging?
That is currently not possible, nor have we any plans to avoid adding it to the history. Any change to a work item creates a new revision, and we want to keep that for auditing purposes. However we are working to improve the history control and one of the future improvements will be to visually filter out changes made by the system.
This is great info as we are designing the next version of the history control on the work item form.
Since we migrated from VSS to TFS the version history shows a single user and day for every commit. The original users and dates for each commit are displayed in the check-in comment.
Is this the best we can do? Isn't there a way to migrate putting the original User into the "User" column and the original date into the "Date" column?
This is the expected behavior. There is no supported way to migrate history from a non-TFS repository and maintain a true history (outside of comments). TFS team does this on purpose so as to maintain the integrity of the audit trail (instead of having TFS "lie" about when that change was checked into TFS).
In practice it is usually sufficient as you still have the changes in the proper order, and if you're going back to inspect history the information you want (date/time, user) is still captured, just not in the ideal location.
Hallo experts,
i'm newbie to TFS, but responsible for SW Test in my group. I'm trying to create a couple of test cases thru MS Visual Studio. I don't know how to change the Test Case IDs, which seem to be automatically assigned by the system. However we want to adapt the IDs to the conventions in our SW specifications. Thanks in advance.
JohnMunich
If what you're looking for is a custom Test Case ID, you'll probably want to modify your work item template for the test cases with a new, custom field.
You can do this by exporting the appropriate work item type using the TFS Power Tools, adding the field and re-importing.
If you want the field to show up in the warehouse, be sure to make it reportable.
Note: The direct link is for the TFS 2010 power tools. This page also contains a link to the TFS 2008 Power Tools.
I don't believe there's any way to do this within TFS itself. These numbers are assigned and internally they are used as primary keys for the data.
You potentially could change the number that will be assigned. I think this might be of help.
The problem is that this will change the next User Story ID that you generate, too.
Does anyone know if it is possible to prevent a work item from being assigned to a specific user account in TFS?
After migrating a TFS from one domain to another, some of my team members have two user accounts, the original one from the old domain, and a new one from the new domain. I'd like to stop work items from being assigned to the old account.
Most process templates restrict username fields with the rule. (If yours doesn't, you should do so.) Then all you need to do is remove the invalid accounts from TFS Valid Users group.
Unfortunately, you can't do this directly -- TFS manages this group automatically based on ACLs found throughout the rest of the system. You have to hunt them down. See these threads for more details:
http://social.msdn.microsoft.com/Forums/en-US/tfsadmin/thread/6e5af2ab-1cbc-4d12-9078-454147926316
http://social.msdn.microsoft.com/forums/en-US/tfsadmin/thread/1ce8b5b0-9924-45ed-919b-49a6a61bb7c7
Once you find all instances where the old domain is being referenced, the general strategy for cleaning up orphans is to add a new ACL, wait for TFS to sync (or iisreset), then remove everything.
However, this may not be possible if you've taken the old domain offline, or there's no trust relationship between the two domains, etc etc. At some point it becomes easier to edit TfsIntegration manually. I usually don't recommend mucking in the TFS databases since it's unsupported and subject to change with every patch. For optimum safety, I'd still strongly suggest using stored procedures rather than trying to interpret the schema relationships (and make sure you hold the necessary locks, etc). prc_security_delete_identity is your best entry point: all you need to know is the old account's SID.