Let's recap Items one more time.
I think #1 and #4 are self-explanatory. We covered #3 in great detail last time. Time to tackle #2. Versions aren't nearly as tricky as names, but there are some historical and terminology issues to cover.
One way to look at the repository is to watch each "slot" over time. ("Slot" is our slang for "server path in committed space.") Every time you checkin a new version of an item, two things happen: a unit of work is recorded, and the new contents of that slot going forward is established.
So far all of this is common to every version control system ever written. In addition, modern version control systems support so-called "atomic checkins." That's actually shorthand for a few related concepts:
Older systems like CVS and SourceSafe didn't have atomic checkins, so a version was a version (or "revision" in CVS terms). Individual items in a modern version control system still have versions, but when we introduced atomic checkins to TFS we needed another word to encapsulate the all the new concepts above. As you probably know, we picked "changeset." Unfortunately, the word doesn't help distinguish between the "two things" (above in boldface) that happen to the repository upon checkin. These two distinct meanings sometimes cause confusion:
That's a lot of words for a really simple distinction. Math terms to the rescue once again. If you think of the repository as a 2D plane like the one pictured above,meaning #1: all points on a line time = <constant>meaning #2: a set of revisions that lie on a such a line
By now it should be obvious that a TFVC operation on "changeset versionspec 20" will affect both a.cs and b.cs, while "changeset #20" only contains b.cs. Unfortunately I don't have a special trick for demarcating which meaning of the word I intend, so I'll try to be unambiguous in future discussions of changesets.