Freigeben über

Version Control

  • Artikel

It's been a while since I posted... I'll try to do better :)

In the meantime, what questions do you have about Visual Studio Team System Version Control? 

I have one: Do you get the changeset model? I don't claim to be an expert in every version control solution out there, but I gather that many folks don't quite understand what a changeset is. Basically, a changeset is a collection of changes. In VSTS, when you check out files, you build up a pending list of changes on your local machine. Think of it as a basket containing all your library books. When you're ready to commit the changes, you check them in (e.g. return the basket of books). Each time you commit a changeset, the entire collection of changes gets assigned a new unique changeset number.

The important point is that until you commit the changes, they're in a <i>pending</i> state on your local machine. The server knows you have a pending edit, rename, delete, etc. and other users can issue the <b>status</b> command to see your pending changes. Other users can also check out the files (assuming you haven't locked them) and pend their own changes. If multiple people have the same file checked out, the first person to check in wins. Subsequent check-ins of the same file may be subject to merge conflict resolution (See Chris's blog for great insights on that).

If you have questions about how this works, please ask. 

cheers!

Comments

  • Anonymous
    November 09, 2004
    Are typical changeset related features also available? Typically in other systems that have changesets, you can "apply/merge" a changeset on another branch or another repository as a unit, etc.
  • Anonymous
    November 09, 2004
    I hope simply modifying the same file by two developers doesn't constitute a conflict in VSTS.

    And you're saying that others can see your pending changes - does it mean that VSTS updates the server every single time I hist Ctrl+S on one of my modified files? Seems like a lot of waste.
  • Anonymous
    November 10, 2004
    Absolutely :) Check out CRathjen's blog for more info on the branch/merge/resolve features of Team System Version Control.
  • Anonymous
    November 10, 2004
    The comment has been removed
  • Anonymous
    November 10, 2004
    How can other users see that I have pending changes if there's no communication with the server until I commit my changes? I'm still not clear on that. You said I issue a pending change request - does that mean that I have to tell the server that I am going to change a file?
  • Anonymous
    November 10, 2004
    The comment has been removed
  • Anonymous
    November 10, 2004
    I've used Perforce for many years now and I just love it. I'm very happy to see that Microsoft is taking the idea of "changelists" into the new system.

    Great work!

    Scott
  • Anonymous
    November 10, 2004
    So it is still using the old lock/modify/unlock model, instead of copy/modify/merge as everybody claims? I think Microsoft is getting confused about terms again, just like when claiming that ASP.NET separates logic from presentation (because they're in two different files).
  • Anonymous
    November 11, 2004
    The comment has been removed
  • Anonymous
    November 11, 2004
    Erv is correct.

    You have the option of locking files when you checkout, if you want. The system admin could also enforce a policy enforcing auto-lock on checkout if that's how your team wants to work. You have the flexibility to decide which model you prefer.

    I'll blog a quick sample of locking/unlocking capabilities soon to get your thoughts & opinions on those features.
  • Anonymous
    November 18, 2004
    We are a small developer that utilizes the current version of VSS. Will this release have the ability to lock down check out/ check in to an active issue? We need to make sure that someone doesn't check out an object and check it back in unless it is associated with an issue.
  • Anonymous
    November 18, 2004
    Yes - for checkins. You will be able to use the included check-in policy for workitems to require, for example, that a checkin be associated with an "approved" bug/workitem. You can also write custom check-in policies to do just about any kind of checks you want. A user will still be able to circumvent the policy - it's not a security feature - but e-mail notification will go out when this happens.

    Check out Jim Presto's blog for more on checkin policies. They're one of my favorite features :)

    http://blogs.msdn.com/jimpresto