Freigeben über

Moving away from item versions

  • Artikel

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

Comments

  • Anonymous
    February 11, 2005
    The comment has been removed
  • Anonymous
    February 12, 2005
    Hmm, perhaps those folks confused by item versions (in addition to changeset versions) should be using Visual Source Safe instead. Note having item versions will be viewed an unusual (putting it kindly) for those of us moving over from other SCM systems (like ClearCase).
  • Anonymous
    February 14, 2005
    Adam: Assume main.cs was changed in changeset #30 and then again in changeset #45. In this case, main.cs#30-main.cs#44 all refer to the same version of the file. So, if you do:

    h diff main.cs;C45-1 main.cs;C45

    then it will compare the version of main.cs previous to version 45 with version 45. It'd be the same as if you did:

    h diff main.cs;C44 main.cs;C45

    or

    h diff main.cs;C30 main.cs;C45
  • Anonymous
    February 14, 2005
    Keith, thanks for your honest feedback - this is exactly what we need :) I can say I'm glad you're still considering moving over from ClearCase!

    I'm also still getting used to not having item versions, but I'm quickly getting used to it. Once the Beta comes out, please play around with this concept and let me know what you think after using it for a few days.
  • Anonymous
    February 14, 2005
    The comment has been removed
  • Anonymous
    February 14, 2005
    The comment has been removed
  • Anonymous
    February 15, 2005
    Presumably it would be easy to have a "previous to tip" alias like ";P" (even if that does look like you're sticking your tongue out). If that would be easy to add, I strongly suggest doing so: I agree with Adam that this is a very common use case. Please don't fall into the trap of assuming that just because the GUI can do it means it's supported. Many of us use scripts to try to automate SCC operations ("try" in my case because SourceSafe's commandline client is so bad from an automatability perspective).

    FWIW, I'm fine with getting rid of item versions.
  • Anonymous
    February 15, 2005
    The comment has been removed
  • Anonymous
    February 15, 2005
    The comment has been removed
  • Anonymous
    February 16, 2005
    The comment has been removed
  • Anonymous
    February 18, 2005
    Buck, can you confirm that if you do "h status /user:* somedirectory" it will list the status of all the files on the directory, without truncating the filename?
  • Anonymous
    March 05, 2005
    Yes. We've considered dropping the local path column of the output of the status command because it tends to cause the lines to wrap. If you are going to use the output of the status command in a script, I would recommend using status /format:detailed. The output is very easy to parse.