If the following happends:
Person Y has a problem with a piece of code
Person Y sends a live share code to person X
Person X edits person Y's code remotely through live share
Person Y checks this code into TFS
Who will be registerd as the author of that changeset?
TFS creates a changeset every time you do a check in.
All the included file changes from your workspace along with the comment, check-in notes, and links to related work items are stored on the server as a single changeset on your server.
Changeset owner/user is just the one who check files into TFS.
So in your case, it should be person Y registerd as the author of that changeset
Related
I just received instructions to add the TFS element number to the comment of any changeset I commit. I find this mesure redundant because I already have to assign the TFS element to my changeset.
I was told it was because it was hard to obtain the list of TFS element a developper worked on.
Isn't there a smarter way to obtain this information?
With using Work Item links between a Changeset and Work Items (the recommended approach - assuming your are using TFVC), you could write a bit of code against the TFS API, or a query against the TFS Data Warehouse to retrieve all changesets by Developer A, then traverse the WI links to find all WI's.
I'm trying to migrate my existing code to TFS 2013 Express.
I have single Team Project Collection and inside it 3 team projects:
-web
-winforms
-wpf
If I add project web-project1 (solution) to team project (for example to web) and check in I get info that change set 1 was saved.
If I add another project (winforms-project1) to other team project (winforms) and check in I get info that changeset 2 was saved.
If I return to first project (web-project1), change something and check in I get information that changeset 3 was saved, but this is my second commit to that project.
Can I configure TFS to have changeset incrementation counter for individual projects instead of one global counter for Team Project Collection?
No, TFS changesets exist across the whole TeamCollection, so are shared amongst TeamProjects.
This allows you to copy and move projects with history and changeset info across TeamProject boundaries.
In your specific example, creating a Web & Winforms TeamProject sounds like you are going about it the wrong way and are starting off at too high a level.
Surely your UI projects could share Business Logic code? Therefore, they should belong in one TeamProject.
Is there a way, by any means, to get the workspace from where a specific check-in was made?
Using Team Foundation Sidekicks I can see the workspace, computer and local path of current checked-out items, but not of changesets. Does TFS keep track of this?
Update
It might help to explain what I really want. Someone performed a check-in using another team member's account (or at least that is what he alleges haha), and I was trying to get to the bottom of this mess by finding the workspace of the changeset because it contains enough information to make a call. Right now the only information I have besides the comment is the date and time, but perhaps there is something else I could use.
Thanks.
Not to my knowledge. I've spent some time looking at our TFS Collection Database, and I cannot find anything that links a changeset to a workspace.
The tables that I've been using have been:
ADObjects
tbl_Workspace
tbl_WorkspaceMapping
tbl_Changeset
tbl_LocalVersion
tbl_PendingChange
Because a workspace only deals with items that are stored on the local machine, I don't believe that information is sent up to the TFS server when a changeset is committed.
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/
We're trailing the use of the built in bug tracking, and have written some integration into our helpdesk software that allows for escalation via workitems.
One thing I haven't found out how to do, is to merge all changes associated with a work item (say to go from dev branch to main) - I appreciate you can double click on a changeset in the merge dialog to view if it is associated with a workitem, and also that I can select individual changesets, and groups of adjacent changesets; but there doesn't appear to be any way to merge changes by workitem?
It is correct that you can't merge based on work items. It is probably not a good idea to do that anyway. It would be very difficult to make sure you get all the necessary changes needed for the main branch to build correctly. I would look into how you do your branching and a good starting point would be: Microsoft Team Foundation Server Branching Guidance
In TFS 2005 and 2008 the check in history will not be transferred between branches. You will get this in TFS 2010.
Merge changesets by workitem - https://tfsprod.codeplex.com/
Check out the ExtendedMerge feature.
Enjoy! :)