LogSubstPol with TFS 2010

Apr 30, 2010 at 9:43 PM

Hello Jochen,


I have gotten your excellant program to work in TFS 2010 with a minor improvement that you may like.

I found a bit of a problem with the $Revision$ replacement in a large project with thousands of files. If I checked in one file, for example, and it got changeset id 720, made changes on another file, checked it so it got 721, and then made a change on the first file again, the new revision of the first file became 720+1, which had already been assigned to file 2.

 First I tweaked the keywords so they would use the actual {7} token instead of {6}+1.


_Keywords.Add(new Keyword() { Key = "Header", Format = "{8}, {7} {1:yyyy}/{1:MM}/{1:dd} {1:HH:mm:ss} {5}" });
_Keywords.Add(new Keyword() { Key = "Id", Format = "{9}, {7} {1:yyyy}/{1:MM}/{1:dd} {1:HH:mm:ss} {5}" });
_Keywords.Add(new Keyword() { Key = "Revision", Format = "{7}" });

Then in class FormatArgs where the assignment is made for {7} I put:

 previousVersionPlusOne = pc.VersionControlServer.GetLatestChangesetId() + 1;

This now gets the last changesetId used in the database and increments. So in my example above, the second change to file 1 above would now result in 722 and will match the View History for the file.

John Zullo

May 1, 2010 at 8:16 AM

This does not work correctly. If you have multiple-check in at the same time, the following might happen:

- One client is going to check in, and it determins the last changeset with 721
- A second client is also going to check-in and it determins also the last changeset with 721
- Then the first check in was done, and it was assigned changese 722 (as you suggested in your code)
- Now the second checkin will take place (on different files, of course), and it will assigned changeset 723! And you write 722 into the file, which is wrong!

Therefor the "Best" solution is to write "721+1" which means: The _next_ revision after 721! This might be 722 or 723 or 729...



Apr 19, 2012 at 3:55 PM

Hello Jochen, Hello John,

Jochen, first I want to thank your for this helpfull addin to TFS. Like others here I wonder why it isn't a standard feature in TFS. Anyhow, with your help ...

As for the ChangesetId I face the same problem like John. I understand your concerns, but I think the risk of real simultanous checkin is pretty low, even in a bigger project. So if there are no other reasons or side effects, I would follow John's proposal and recommend to implement it in the official version. Otherwise you get really fast strange results in the file history. The 721+1 strategy in my oppinion makes life difficult, if you have to do some archaeological research in the repository ;-)

John, if you are still listening. Could you give us a short statement on your experiences.

Thanks both of you and best regards.