Buck Hodges

Visual Studio Online, Team Foundation Server, MSDN

June, 2004

  • Buck Hodges

    Out for the week

  • Buck Hodges

    TechEd C# presentations

    Duncan Mackenzie just posted a link to the C# TechEd 2004 page that has slides from some of the presentations (more to come).  Cool!
  • Buck Hodges

    VSTS pricing


    There have been questions about pricing in the newsgroups.  Here is what Raju Malhotra had to say about it.  As I understand it, many of the pricing details have yet to be worked out and are far from being set in stone.

    We will share the specific pricing details with you as soon as they are finalized but here is what we know. Hope this helps.

    MSDN Universal customers will have an option to get any one of the VS Team Architect, VS Team Developer or VS Team Test products as part of their subscription without paying anything extra as long as their subscription is current at the release time. Of course, all other benefits of their subscription like monthly shipments, access to subscriber download site, MS servers for dev/test purposes, etc. will continue as usual. They will also be able to migrate to the full suite (including all three of the above prducts) at an additional price to be announced later. In general, the pricing for VS Team System products will be competitive with the lifecycle tools market.

    We will also have upgrade paths available in retail. We are currently working on the upgrade eligibility and specific pricing for that.

    Please stay tuned for more details.

    Raju Malhotra
    Product Manager,
    Visual Studio Team System

  • Buck Hodges

    Interfaces for the TFS source control client


    The new source control system in Team Foundation will have several client interfaces.

    Command line   The command line interface provides a complete set of commands for performing all of your source control tasks.  When run interactively (i.e., the /noprompt option is not specified), some commands will bring up dialogs.  These commands include workspace for defining editing workspaces, history, resolve, checkin, and a few others.  If you use the built-in diff tool or configure your own (Beyond Compare, Araxis, etc.), the diff command will bring up GUI diff window.  Scripts will use the /noprompt option to suppress dialogs, as well as those who don't want a GUI.

    Visual Studio   The Visual Studio Team Foundation source control integration will far exceed the level of functionality available in prior versions.  Without opening a solution, you'll be able to browse the repository, create and manage labels, view history, open a solution, etc.  It's intended to provide a level of functionality similar to what exists in the Visual SourceSafe Explorer.  Once you open a solution, files will be automatically checked out when you edit them, you'll see a list of pending changes in the checkin window, you'll be able to associate work items (bugs) with the changes, establish checkin policies, and add notes to each checkin.

    Visual Studio Shell   This interface will be the Visual Studio GUI but without all of the compilers, debuggers, profilers, etc.  It's intended to provide the source control, work item tracking, and other parts of the Team System GUI without the coding tools, resulting in a much smaller footprint for users who need access to Team System but aren't writing code.

    There is also a client API, written in .NET, for writing applications to perform source control operations.  The client API is used by the command line and Visual Studio integration as well.


  • Buck Hodges

    A simple example using branch and merge


    Merge is an overloaded word. There is a content merge and then there is a branch merge. A content merge is where you have edited a file and someone checked in a newer file, so the source control system will tell you to do a content merge before checking in the file (if it's interactive, it's a 3-way merge GUI).

    A branch merge is migrating changes from one branch to another. If a source branch A has a file rock.cs that had been edited and file scissors.cs that had been deleted, merging these changes into a target branch B would result in a pending edit on file rock.cs and a pending delete on the file scissors.cs in the target.

    Here's a simple example that uses the command line.  The biggest differences between this and a “real-world“ example are the number of files involved (you may have thousands) and that you would probably have conflicts for a subset of the files (e.g., the same file was edited both in the source and in the target, resulting in the need to do a 3-way content merge).

    The /i option is the shortcut for the "noprompt" option that makes everything non-interactive, as would be needed in batch script. Changes are committed in change sets, and the whole check in either succeeds or fails (it's atomic).

    1. Create a workspace and add the files mentioned in the merge explanation above.

    D:\project>h workspace /i /new MyProject
    D:\project>h add /r A
    D:\project>h checkin /i
    add A
    add rock.cs
    add scissors.cs
    Change set #4 checked in.
    2. Create a branch from A to a target B.
    D:\project>h branch A B
    D:\project>h checkin /i
    branch B
    branch rock.cs
    branch scissors.cs
    Change set #5 checked in.
    3. Now we have A and B in the repository, related by B being a branch of A.
    D:\project>h dir /r
    6 item(s)
    4. The branches command shows that B is branched from A.
    D:\project>h branches A
    >> $/A <<
         $/B Branched from version 1
    5. Now we edit rock.cs and delete scissors.cs in the source branch.
    D:\project>h edit A\rock.cs
    D:\project>echo new line >> A\rock.cs
    D:\project>h delete A\scissors.cs
    D:\project>h checkin /i
    edit rock.cs
    delete scissors.cs
    Change set #6 checked in.
    6. Merge the changes made in branch A over to branch B. Of course in a real project, there may be conflicts to resolve (rock.cs may have been edited both in the source and target, which will need to be merged with a 3-way content merge), and the developer may need to make additional changes in B (for example, B may be a newer release of the project and the code may be need to be changed due to an API change made earlier in B).
    D:\project>h merge A B
    merge, edit: $/A/rock.cs;C5~C6 -> $/B/rock.cs;C5
    merge, delete: $/A/scissors.cs;C5~C6 -> $/B/scissors.cs;C5
    D:\project>h checkin /i
    merge, edit rock.cs
    merge, delete scissors.cs
    Change set #7 checked in.
    6. In the history, we see that B\rock.cs was created by branching in change set 5 and then an edit was merged in change set 7.
    D:\project>h history /i B\rock.cs
    Vers Date       Chngset User          Change Type          Files
    ---- ---------- ------- ------------- -------------------- --------------------
       2 06/14/2004       7 buckh         merge, edit          $/B/rock.cs
       1 06/14/2004       5 buckh         branch               $/B/rock.cs
  • Buck Hodges

    More on branching and merging vs. sharing and pinning


    Branching and merging in TFS provide a more robust way to accomplish what sharing and pinning are often used for in VSS.  In TFS, you would branch a directory (source), using the "branch source target" command, to the desired location (target).  Then when there are changes in the source that you need in the target, you would use the "merge source target" command to propagate the changes.  The merge command remembers what changes have have been brought over to the target, so it brings the target up to date with the source by only merging changes that have not been merged.

    The merge command will pend edits, branches for files added, deletes, etc. in the target (in TFS, commands pend changes and then the checkin command submits all changes in a single atomic operation).  After running the merge, command you would then build the software and test it.  Additional changes may need to be made in the target, such as when you change a function or method signature.  When everything is ready, you would check in the merged changes, along with any other changes you needed to make, in a single atomic operation.

    By doing this, you are able to build and verify before checkin each branch when it merges in the changes from the source.

    There is no penalty in TFS with respect to having multiple branches of the same file.  In the SQL database, they all reference the same content.  Only when a branched file changes does new content get added.

    With respect to merging binary files, there is nothing to do except run merge followed by checkin if the binary files in the target do not change.  If binary files in the target have changed, the merge command will produce conflicts for those files, and you would have to pick which to keep (source or target -- there is no 3-way content merge option, of course) when resolving the conflict.

    If you want to have every project always use the same same file and immediately see new versions as soon as they are checked in, putting the file in a common location in the TFS repository, such as $/public/bin/dlls, is the way to go.  That does mean that everything that references it should use relative paths.  And since there is no isolation, everything that depends on the file must be checked prior to checkin, or you run the risk of silently breaking other projects (i.e., it requires manual coordination).

  • Buck Hodges

    When can I get the Team Foundation Server?


    Several people have asked this question.  The server is not included in the May Community Preview distributed at TechEd.  Also, the server bits will not be included with the upcoming VS 2005 Beta 1 release.  In fact, none of Team System will be in Beta 1, so the May Community Preview release at TechEd is it for a little while.

    The server will be available in a Team System community drop later this year.

  • Buck Hodges

    Migrating from SourceSafe to Team Foundation Server


    We plan to provide migration tools for users switching to TFS.  A VSS user asked in the newsgroup about migrating VSS labels, revision history, sharing, and pinning.

    The goal is migration of all data, consisting of projects, files, and folders, with associated metadata reliably with minimal information loss while preserving user information and appropriate permissions.  There are some features in VSS that do not translate to TFS.  The following is quick overview of the preliminary plan.

    • Users and groups in TFS are Windows accounts (it uses standard NTLM authentication).  SourceSafe identities will be migrated to Windows accounts. 
    • Labels and revision history will be preserved.  With regard to revision history, TFS supports add, delete, rename/move, etc.  It does not support destroy/purge in V1.
    • TFS does not have the equivalent of sharing, so the current plan
      is that the migration tool will handle that by copying.  Each copy will have its own history of the common changes made after the file was shared.  VSS branching is migrated in a similar fashion.
    • Pinning and unpinning are also not available in TFS.  The current plan is that for any item currently pinned, the user will be given the option to either ignore the pinning or to assign a label to the versions that are pinned and lock them.
    • TFS does not support the VSS archive and restore features.

    That is a very quick summary of the plan, which may change.  We welcome your feedback.

  • Buck Hodges

    12 GB CompactFlash card


    Of course you can get microdrives, but if the moving parts make you nervous, Pretec offers a 12 GB flash card.  It's only $14,900.  Then you'll need a $60,000 digital camera to go with it.  Somehow that nifty $3,000 Nikon D2H just seems inadequate.


  • Buck Hodges

    VSTS Newsgroups

    The VSTS 2005 page mentions the newsgroups for VSTS (in the Community Resources section beside the "Ask the Team" column). It doesn't stand out, though, and so a lot of people may not realize they are there. The newsgroups are actively monitored by a large number of VSTS folks, so it's a great way to interact and provide feedback (you'll usually get a quick reply to any question you post there).

    You can read the newsgroups just using your browser at http://communities.microsoft.com/newsgroups/default.asp?icp=whidbey&slcid=us. The browser interface isn't very good for keeping up with the newsgroups, though.

    Viewing these Newsgroups with an NNTP Newsreader 

    You can use Outlook Express or other NNTP newsreader.  Since these are private newsgroups, your server will require you to logon using the following information:

    • Server: privatenews.microsoft.com
    • Account name: privatenews\VSUser
    • Password: Password
    • Note that the password is case-sensitive.
    Here is the list of the newsgroups with rough descriptions.
    • Microsoft.private.whidbey.teamsystem.general - VSTS overall
    • Microsoft.private.whidbey.teamsystem.architect - modeling and design tools (Whitehorse)
    • Microsoft.private.whidbey.teamsystem.architect.appdesign - Whitehorse app designer
    • Microsoft.private.whidbey.teamsystem.architect.deployment - Whitehorse deployment designer
    • Microsoft.private.whidbey.teamsystem.developer - developer tools (PreFast, FxCop, Perf tools)
    • Microsoft.private.whidbey.teamsystem.developer.classdesign - Whitehorse class designer
    • Microsoft.private.whidbey.teamsystem.tester - testing tools
    • Microsoft.private.whidbey.teamsystem.projectmanager - project management tools
    • Microsoft.private.whidbey.teamsystem.teamfoundation - source control, change management, work item tracking
  • Buck Hodges

    Branching models


    Doug Neumann, our PM, posted on the Team Foundation newsgroupmicrosoft.private.whidbey.teamsystem.teamfoundation newsgroup a nice answer to a question about branching models and VSTS.

    Question (Carl Daniel):

    IEEE Computer, September 2002 issue contained an article entitled "the importance of branching models in SCM". Since we can't really evaluate the Team System SCM without the server component, perhaps someone from the Team System team at MSFT could comment on how Team System SCM fits into thebranching scenarios described in this article.

    The article is also available at http://www.seapine.com/pub/papers/SCMBranchingModels.pdf in case you don't have IEEE Computer handy.

    Answer (Doug Neumann):

    That's a good article, thanks for the pointer.

    The answer to your question is that we give you the tools to implement any of the models outlined in this article.

    Here's a quick overview of the power of branching and merging in the VS Team System:

    * Path-space branching -- branches are created within the path structure of the repository, similar to file copy operations. In talking to users, we find that this model is much easier to visualize, and is actually what they really want to do. They want a copy of the source that can evolve asynchronously and that's what we give them.

    * Support for merging namespace changes -- many SCC systems focus on merging content changes that have occurred to a specific file between 2 branches. We take a broader view of merging changes and focus on merging all types of changes between branches. Thus, we're able to merge file adds, deletes, moves, renames, etc. as part of your standard merge operation.

    * Changesets -- changes that are committed together are managed as a single entity called a changeset. Thus, when it comes time to merge a change to a new branch, you don't have to wrack your brain trying to figure out the full list of files you need to operate on. Just tell us which changeset you want to merge and we'll do it all for you.

    * Cherry-pick merges -- you can merge specific file change to another branch without merging the changes that were included in previous versions of those files. Thus, if you've got 2 bug fixes which touch the same file, you can merge the second one without merging the first.

    * Merge candidate queries -- you can ask the system for a list of all changes which haven't yet been merged between 2 branches.

    * Merge history queries -- you can ask the system for a list of all changes that have ever been merged between 2 branches.

    The authors of this article seem rather partial to their "Branch by Purpose" model, so let's talk about how that would work in the Team System.

    We'll setup a mainline for most of our development work and put it in the repository at $/Application/Main. During the development phase, all of our new features and bug fixes are going into this line. When we are feature complete, we branch the main line to work on one or more release branches. To keep it simple, let's say we've got a single release branch which we'll put at $/Application/Release. If we have other feature work that we want to occur in parallel, we could also branch the main line to create a bridge branch at $/Application/Bridge.

    After feature complete, we enter the "code chill" mode where we're only submitting bug fixes to the main line. We have some cool mechanism in VSTS that will allow you to control what changes can get checked into the mainline during this period (if you want to hear about those, post another follow-up). At any time, we can run a query to get a list of all changesets that have been committed to the main line but not merged to the release branch. We can then cherry-pick those changes as necessary (we don't have to take them all) or merge over all changes if desired.

    When we stabilize that release line, we enter code freeze at which point release candidates are produced. According to the article, any fixes needed for the release candidate are checked directly into the release branch, although I don't see why they couldn't also follow the model of code chill. Either way, you can merge the changes either direction between the main line and the release branch to make sure the fix is in both places.

    In the article, they branch for the actual release, but they don't show any changes on this branch. If it's not going to evolve, you can accomplish the same goal by slapping a label on the items that were included in the release. If you determine later on that you need to make changes to the release, you can always create the new branch from the label. If you're going to be releasing hotfixes for individual bugs, you might want to branch for each hotfix and then merge the changes back into the release branch (where your maintenance work is happening).

    Hope that helps. Post a follow-up if you'd like more detail. Also, I'd be interested to hear what you think of the strategies in this article. I have my own philosophy on this stuff that I'll save for another time.

Page 1 of 1 (11 items)