Source Control for Team Foundation, Presentation Notes

  • Article

I’m sitting here in the San Diego Convention Center’s Tent Pavilion in cabana #6, listening to Doug Neumann, the source control PM on the Visual Studio 2005 Team System team, talk about how to manage software configurations with Visual Studio 2005.

Ninety percent of the 40-50 people in the audience use Visual Studio and ninety-nine percent are experiencing “growing pains” with Visual SourceSafe. How does that work? Anyhoooo,

One guy points out that Doug doesn’t have a blog yet.  I yell, “But Brian Harry does.”

For complete notes, including Doug’s unscripted responses to some *tough* customer questions, see my article: Source Control for Team Foundation, Presentation Notes

Slide #0: Agenda
What is SCM? What is Visual Studio Team Foundation? What SCM features does Team Foundation include?

Slide #1: What is Software Configuration Management?
SCM is more than just version control. SCM is “the set of strategies employed for managing the integrity and evolution of a base of source code.” SCM consists of source code control, work item tracking, build management, and release management.

Slide #2: Goals of Visual Studio 2005 Team System
Reduce complexity, Enable Partners, Facilitate Communication

Slide #3: Team System Editions
Team Architect, Team Developer, Team Test, Team Foundation

Slide #4: What about SourceSafe?
It’s alive and kicking
            VSS R&D continues
            New release in VS2005
SourceSafe is for small teams
            1-5 users, version control only. Not a complete SCM solution.

Slide #5: Visual Studio Team Foundation
For larger teams…5-500 users…complete SCM system
Doug adds, ”This system will support all of Microsoft’s development efforts in the future.”

Customer Question: What new features would motivate me to move from VSS to Hatteras:
Answer: Integration with work item tracking; New and cool versioning features (ie,
Shelving…to be discussed later in talk); Performance; Security…

Slide #6: Workspace Isolation
How do I work on new features without destabilizing my co-workers?

  • Developers need a sandbox.
  • In Team Foundation, all of your personal changes are isolated to a “workspace” on your machine. TF allows you maintain multiple workspaces per machine which precludes the complicated solution binding management that VSS requires to perform the same operations.
  • working folders and cloaks
  • Multiple checkouts (just like VSS)
  • ALL of your changes (move, branch, delete, rename) are staged for checkin, even if it isn’t in your current solution
  • Changes are submitted as a changeset, atomically and transactionally, either all 5 changes are checked in or none of them are.

Question: Are database artifacts versioned in the repository?
Answer: Nope, not in V1.

Question: Can I store a stripped-out stored procedure, for instance, in the repository?
Answer:Yes, you can store anything that is a file. In fact, the Hatteras team does this using a script.

Slide #7: Create Workspace from Command Line Demo
If you use Visual Studio, we create the workspace for you. From the cmd line: workspace same name as computer, by default.

Cloak Feature: If there’s a certain part of the repository that you don’t care about or won’t be working on, you can create a cloak during workspace creation to avoid having to download those files to your local workspace.

C:\cabana6>h get
Downloads all files from the specified repository path (recursively) to the root of your local workspace. If you perform the operation again, immediately, nothing happens since no changes have been made to any of the files in your workspace.

Slide #8: Parallel Development
“How do we maintain different application trajectories as required by our business?”

  • Configurations sometimes need to diverge.
    • Requires that you maintain a green field branch and one maintenance branch.
    • team isolation
    • custom application development
  • Configurations must sometimes converge
    • you need to be able to identify differences between configurations
    • you need to be able to merge changes

Slide #9: Branching

  • Team Foundation branches are created in path space, not “version space”
    • akin to a file copy
    • simplifies version numbers (not like CVS complicated numbering system)
    • helps you quickly determine branch relationships
  • Branch ancestry is enumerable

Interesting Tidbit: Doug was a CVS user in a past life.

Slide #10: Merging

  • Team Foundation offers powerful merging
    • Merges all branch changes
    • you can cherry-pick changes to merge
    • you can enumerate merge history
    • you can calculate merge candidates

Slide #11: Branching and Merging Demo
You can query for changesets status, you can ask “What changesets exist in my green field branch that have not been merged into my maintenance branch.”

\>h checkin…”change set #4 checked in”

Merge occurs in local workspace.  “If you’re a good developer”, Doug says, “you would then build and run tests on the workspace version of your project before checking in changes to the repository.” Dang, that’s why I’m not a good developer.

Slide #12: Configuration “Snapshots”
How do I capture a configuration so that it can be recreated in the future?

Labels

  • labels allow you to “capture source revisions” with a friendly name\
    • labels can be easily categorized for easy searching
  • Team Foundation allows you to re-use label names in different repository trees!

Interesting Tidbit: ~75% of the audience uses labels extensively. 0% never use labels.

  • Use label names instead of versions
    • you can retrieve source revisions by label name
    • you can merge changes from a label

Customer Question: when you create a branch, does it create a new copy of all files.
Answer: No, not in the repository but current plans are to create a copy of all files on your local computer.

Question:What if the branch consists of a huge number of files and takes up too much space?
Answer: Buy more memory or cloak the parts of the workspace that you don’t need… (this appears to be an open issue. What do YOU think?)

Slide #13: Change Tracking
How do we account for the source changes being introduced to the system?

  • changes need to be accounted for
    • you need to know why the change was made and who authorized it?
  • work needs traceability to source
    • you need to be able to figure out what change fixed a bug (or caused it)?
  • Source comments aren’t always enough to describe what occurred between revisions.

Well… with Team Foundation:

Work definition is managed in a work item tracking system. A work item includes, requirements, tasks, defects, DCRs, etc.

  • work implementation managed in source control
  • you can easily associate work items with a source control checkin during checkin
    • initiates workflow

Slide #14 Associating Work Items with Source Revisions
All you have to do is click a checkbox in Visual Studio’s Pending Checkin window for a work item (a work request, for example) to associate it with the changeset.

Question: is there a way to associate a work item with more than one changeset, or only 3 of the 6 files within that changeset.
Answer: Yes, but you have to check in at different times.  The right thing to do is to check in twice so that each changeset has a discrete purpose.

Question: Can you relate two or more bugs.
Answer: Yes.

Question: which team is developing work item tracking?
Answer: The same team as source control.

Question: Does it integrate with Microsoft Project.
Answer: Absolutely.

Slide #15: A Killer New Versioning Feature
How do I handle unfinished work when faced with shifting priorities and assignments?

  • Sometimes more important work crops up or work assignments change
  • Does your SCM system help you?  Team Foundations does.

Slide #16: Shelving

  • The Shelve feature allows you to store work-in-progress on the server
  • you can optionally restore unmodified files

Slide #17: Shelve Scenarios

  • Use when you need to switch tasks without intermixing changes
  • create a “checkpoint”
  • backup work w/o checking in
  • or transfer work between team members/systems.

Doug Asks: How many of you check in your changes at the end of every day.
Answer: 20% raise hands.
The problem with daily checkins is that it forces you to check in changes that don’t compile or which might break the build.

Shelving allows you to “partially checkin” a changeset

Question: Is shelving label-based or stack-based? 
Answer: It’s more like a private branch without the task overhead.

Question: What it is that a Team Foundation customer “shelves” exactly? Individual files or the changeset? 
Answer: Technically, the files.

Question: can you diff shelved changes?
Answer: Yes, on a file by file basis (gets a copy of the file to a new location.)

Doug asks, “How many of you think you might want that feature?”
Response: Everyone raises their hands.

Slide #18: Maintaining Source Integrity
How do we ensure that source changes don’t damage the code base?

  • To do so, you need to enforce a quality bar, define a policy for appropriate operations, and you need to be able to customize those policies as necessary

Slide #19: Checkin Policies

  • Policies provide you with a way to validate that checkins comply with your organizational standards (ie, unit testing and static analysis, which checks for common coding mistakes such as gotos and syntax errors, etc)
  • checkin policies can be overridden, if necessary
  • can be customized by your organization

Slide #20: MSBuild

  • IDE build == system build
  • reproducible nightly build on the desktop
  • extensible build system. Builds launched inside the IDE.

Question: Does Team Foundation provide continuous build integration?
Answer: We’re not providing one for v1 but you can easily hook into our events to initiate your own builds (like CruiseControl.Net) using our automated build process

Team Foundations builds can be run nightly, at intervals of your choosing, or on demand.

Slide #21: Team Communication
How do we capture and communicate the correct information about source changes?
Team Foundation provides email notifications for events such as checkin.

Question: How well does Team Foundation support disconnected work and remoting?
Answer: we have really worked on performance for teams with slow connections. It is orders of magnitude better than VSS.
Answer2: offline operations are possible but you must perform such operations manually, by flipping the read-only bit.