Moving away from item versions

Based on customer feedback, we've decided to cut the concept of item versions from Team Foundation Version Control. In previous releases (including the Dec. CTP release), you could refer to any version of a file or folder by its item version. The item version was incremented each time you checked in a change to the file or folder, and it increased with a step of 1. You could also (and still can) refer to the versions via the number of the changeset in which it was committed (the changeset version).

As usual, an example will probably clear this up better than my poor explanation above:

Say you add a file called main.cs and check it in as part of changeset #105.  The item version of this versin of the file in the repository is 1, but its changeset version is 105.

Now, some other developers on your team check in changesets #106 and #107 containing other files, but not main.cs.   

Now suppose you check out main.cs again, modify it, then check it in again as part of changeset #108. The item version would be 2, but the changeset version is 108.

We got plenty of feedback that having multiple version representations of repository items was confusing. So, going forward, you can refer to anything by its changeset version. Item versions are no longer tracked.

Of course, this begs the obvious question... What if I specify changeset version #107 for main.cs in the example above? It wasn't part of that changeset. If you ask for this (e.g. h get main.cs;C107) - what would you get? 

The answer is that you'd get the most recent version of the file as of changeset 107, or in other words, the version you checked in with changeset #105.

Well, there ya go... I hope I haven't confused you more. If you have strong opinions or feedback about this decision, please leave comments & let us know what you think.

Related to this, Chris just blogged about workspace versions.

Have a great weekend!

-Jason