What to do when history ends with delete, source rename?
As you probably know, one of the biggest changes in the version control part of TFS 2010 was moving from item mode (files and folders are uniquely tracked by itemId) to slot mode (itemId is attached to a slot and renaming file or folder changes its itemId). Matt wrote more about it here.
Of course when we made this change, we had to ask ourselves how much we want to try to pretend on the client level, that everything is the same way as in TFS 2008. Soon we understood that we can’t completely hide we should provide tools that allow user to find all information he needs about given file, the same way as in the previous versions. Most often the tool we are talking about is History, that allow us to track file changes across merges, branches and renames.
One situation when history does not provide all information user (or at least user, who is new to slot mode) expects is when he start tracking history, by specifying file name before the rename. For example:
7 rename michal 12/31/2009 1:30:18 PM $/michal1/1/MyAddin1/MyAddin12/Connect2.cs
6 rename michal 12/31/2009 1:30:02 PM $/michal1/1/MyAddin1/MyAddin1/Connect2.cs
5 add michal 12/31/2009 9:13:46 AM $/michal1/1/MyAddin1/MyAddin1/Connect.cs
user specifies:
tf history $/michal1/1/MyAddin1/MyAddin1/Connect2.cs
and sees the following dialog:
Now he doesn’t know what happened after file was renamed in the changeset 6. The only information we have is that it wasn’t deleted, it was renamed - “source rename” tells us that.
So what we can do? We have 2 choices:
- We can open changeset 6 and see what item has a rename change. This is very easily done from the history dialog, but may not be conclusive if there were more than one rename in the changeset:
- We can open history in the item mode: “tf history $/michal1/1/MyAddin1/MyAddin1/Connect2.cs /itemmode”. This way we will see history of this item, the same we would see it with VS 2008. Unfortunately we can do it only from the command line.
Happy New Year!