Tracability of a "RENAME" in ChangeSets with the API
Hi,
I would like to know if the APIs can help me to find the previous name of a file marked as "Rename" in a ChangeSet.
When I loop on the "Change" objects in a ChangeSet marked as "Rename" in ChangeType, I can only get the new filename with the "ServerItem" property, but not way to get the filename before the rename.
When I query the history with the renamed filename, the history is empty.(only the last/renamed version can be found)
So, the only solution I found is to iterate through all previous changeset and to stop when I found a ChangeSet with a change having an item with the same ItemId...
I hope there is a better solution...
any idea ?
Sincerely,
Daniel
Hello,
Well, I can feel your pain. It would be mighty nice if the Item class would contain RenamedId (similar to DeletionId) so it would be easier to get to item previous name.
But it is very strange that you cannot use QueryHistory to retrieve all history by new item name. The following snapshot works for me:
IEnumerable coll = VersionControl.QueryHistory(item.ServerItem, LatestVersionSpec.Latest, 0,
RecursionType.None, null, null, null, Int32.MaxValue, true, false);
foreach (Changeset cs in coll)
;// Do something
In fact, that is the code used in History Sidekick, which displays all of the history for renamed item. So it appears that it may be related to some of the parameters you query history with.
Regards, Eugene
Eugene is right. In fact, you can pass any valid name+version to QueryHistory. For example, if the file names are:
$/a;C1
$/b;C2
$/c;C3
Then you can call QueryHistory("$/a", new ChangesetVersionSpec(1), ...) and so on for the other names. In each case you'll get the same complete (across renames) back. However, QueryHistory ("/b", LatestVersionSpec.Latest, ...) will not work.
It would be mighty nice if the Item class would contain RenamedId (similar to DeletionId) so it would be easier to get to item previous name.I don't really follow. The ItemID is always constant no matter how many times it's renamed. A DeletionID is necessary to (a) group items affected by the same recursive delete (b) disambiguate multiple deleted items with the same name. You can find (a) by doing a recursive QueryItems @ the time of the rename, and (b) does not apply.
Richard,
My bad about ItemId. Would be too easy...
I was thinking that it would be nice to have some indication on that item that it was renamed. Right now, only way I know of to find that item would be QueryHistory. Do you have any alternative idea?
I had a bit of headache about renamed items - as for example when performing get by item path and some changeset version in the past, and the item had other name at that point, it gave me error. How would you solve that?
And also, I think you can do multiple renames (to the same name) - say Class1.cs, Class2.cs and Class1.cs. How do you solve ambiguity here?
And if we at the topic already (kinda found wishing well and can wish whatever wish), are moved items handling different from renamed items?
Thanks beforehand.
Yours truly, Eugene
I can't think of anything better than QueryHistory for tracking an item over time. That's what it's for :) To solve your "headache," get the old name from QueryHistory(knownName, knownVersion, 0, RecursionType.None, null, desiredVersion, desiredVersion, 1, true, false)
There shouldn't be ambiguity. A server path + versionspec always resolves to exactly 0 or 1 item. That's why QueryHistory needs a 3rd versionspec ('knownVersion' above) as well as versionFrom and versionTo.
Moves and renames are the same. I guess you could say renames are a special case of moves, but we go the opposite route and call everything "rename" by convention.
I'm writing a long series of blog posts that should help to sort these concepts out. It'll take awhile to get to fun stuff, but you may as well subscribe now: http://blogs.msdn.com/richardb
Thanks Eugene,
You are right,...it works with the use of QueryHistory.
Sincerely,
Daniel
 Richard Berg MSFT wrote: |
...
There shouldn't be ambiguity. A server path + versionspec always resolves to exactly 0 or 1 item. That's why QueryHistory needs a 3rd versionspec ('knownVersion' above) as well as versionFrom and versionTo.
Moves and renames are the same. I guess you could say renames are a special case of moves, but we go the opposite route and call everything "rename" by convention.
I'm writing a long series of blog posts that should help to sort these concepts out. It'll take awhile to get to fun stuff, but you may as well subscribe now: http://blogs.msdn.com/richardb
|
|
Thanks very much for the clear explanation Richard. Are there any plans to completely remove such confusions by upgrading the MSDN documentation? I really hate to search through forums and blogs for information when all these stuff should be available in a quality online doc. Have a look at the current api documentation on queryhistory:
http://msdn2.microsoft.com/en-us/library/bb138960(VS.80).aspx
don't you think it's crying out for improvement?
