Buck Hodges

Visual Studio Online, Team Foundation Server, MSDN

January, 2005

Posts
  • Buck Hodges

    Team Foundation Source Control client API example

    • 16 Comments

    Here's a really simple example that uses the source control API () in the Dec. CTP.  It shows how to create a workspace, pend changes, check in those changes, and hook up some important event listeners.  This sample doesn't do anything useful, but it should get you going.

    You'll need to reference the following dlls to compile this example.
    System.dll
    Microsoft.VisualStudio.Hatteras.Client.dll
    Microsoft.VisualStudio.TeamFoundation.Client.dll

    If you write something with the API, please send me email or leave a comment.

    using System;
    using System.Collections.Generic;
    using System.IO;
    using System.Text;
    using Microsoft.VisualStudio.Hatteras.Client;
    using Microsoft.VisualStudio.TeamFoundation.Client;

    namespace BasicSccExample
    {
        class Example
        {
            static void Main(string[] args)
            {
                // Verify that we have the arguments we require.
                if (args.Length < 1)
                {
                    Console.Error.WriteLine("Usage: app tfsName");
                    Environment.Exit(1);
                }

                // Get a reference to our Team Foundation Server.
                String tfsName = args[0];
                TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer(tfsName);

                // Get a reference to Source Control.
                SourceControl sourceControl = (SourceControl) tfs.GetService(typeof(SourceControl));

                // Listen for the Source Control events.
                sourceControl.NonFatalError += Example.OnNonFatalError;
                sourceControl.Getting += Example.OnGetting;
                sourceControl.BeforeCheckinPendingChange += Example.OnBeforeCheckinPendingChange;
                sourceControl.NewPendingChange += Example.OnNewPendingChange;

                // Create a workspace.
                Workspace workspace = sourceControl.CreateWorkspace("BasicSccExample", sourceControl.AuthenticatedUser);

                try
                {
                    // Create a mapping.
                    workspace.CreateMapping("$/", @"c:\temp\BasicSccExample");

                    // Get the files from the repository.
                    workspace.Get();

                    // Create a file.
                    String topDir = Path.Combine(workspace.Folders[0].LocalItem, "sub");
                    Directory.CreateDirectory(topDir);
                    String fileName = Path.Combine(topDir, "basic.cs");
                    using (StreamWriter sw = new StreamWriter(fileName))
                    {
                        sw.WriteLine("revision 1 of basic.cs");
                    }

                    // Now add everything.
                    workspace.PendAdd(topDir, true);

                    // Show our pending changes.
                    PendingChange[] pendingChanges = workspace.GetPendingChanges();
                    Console.WriteLine("Your current pending changes:");
                    foreach (PendingChange pendingChange in pendingChanges)
                    {
                        Console.WriteLine("  path: " + pendingChange.LocalItem +
                                          ", change: " + PendingChange.ChangeTypeToString(pendingChange.ChangeType));
                    }

                    // Checkin the items we added.
                    int changesetNumber = workspace.CheckIn(pendingChanges, "Sample changes");
                    Console.WriteLine("Checked in changeset " + changesetNumber);

                    // Checkout and modify the file.
                    workspace.PendEdit(fileName);
                    using (StreamWriter sw = new StreamWriter(fileName))
                    {
                        sw.WriteLine("revision 2 of basic.cs");
                    }

                    // Get the pending change and check in the new revision.
                    pendingChanges = workspace.GetPendingChanges();
                    changesetNumber = workspace.CheckIn(pendingChanges, "Modified basic.cs");
                    Console.WriteLine("Checked in changeset " + changesetNumber);
                }
                finally
                {
                    // Delete the items.
                    workspace.PendDelete("$/*", RecursionType.Full);
                    PendingChange[] pendingChanges = workspace.GetPendingChanges();
                    if (pendingChanges.Length > 0)
                    {
                        workspace.CheckIn(pendingChanges, "Clean up!");
                    }

                    // Delete the workspace.
                    workspace.Delete();
                }
            }

            internal static void OnNonFatalError(Object sender, ExceptionEventArgs e)
            {
                if (e.Exception != null)
                {
                    Console.Error.WriteLine("Non-fatal exception: " + e.Exception.Message);
                }
                else
                {
                    Console.Error.WriteLine("Non-fatal failure: " + e.Failure.Message);
                }
            }

            internal static void OnGetting(Object sender, GettingEventArgs e)
            {
                Console.WriteLine("Getting: " + e.TargetLocalItem + ", status: " + e.Status);
            }

            internal static void OnBeforeCheckinPendingChange(Object sender, PendingChangeEventArgs e)
            {
                Console.WriteLine("Checking in " + e.PendingChange.LocalItem);
            }

            internal static void OnNewPendingChange(Object sender, PendingChangeEventArgs e)
            {
                Console.WriteLine("Pending " + PendingChange.ChangeTypeToString(e.PendingChange.ChangeType) +
                                  " on " + e.PendingChange.LocalItem);
            }
        }
    }

  • Buck Hodges

    VSTS and MSDN Universal

    • 11 Comments

    Back in June I posted information from the newgroup regarding VSTS Pricing.

    Here's an update from Ajay Sudan's newsgroup post (Jan. 24, 2005).

    MSDN Universal customers may migrate to their choice of
    Visual Studio Team Architect Edition, Visual Studio Team
    Developer Edition, or Visual Studio Team Test Edition at
    no additional cost for the duration of their MSDN
    Universal subscription.

    MSDN Universal customers may also elect to migrate to
    Visual Studio Team Suite at an additional cost. Detailed
    pricing/licensing for Visual Studio Team System will be
    announced in early March.
  • Buck Hodges

    How to use shelving from the command line

    • 4 Comments

    Shelving is a really useful feature that was included for the first time with the Dec. CTP.  Shelving allows you to save your changes to a shelveset on the server.  The shelveset consists of the same kind of information that a checkin does, except that you aren't checking in.  You don't create a new changeset.  Rather, you create a space on the server that is your own that contains your pending changes, comment, etc.

    You can choose to move your changes out of your workspace or you can keep your pending changes when you shelve.  Moving your changes is great when you need to stop working on your current changes, make a targeted fix, check in that fix, and then unshelve what you were working on before being interrupted.  Keeping your changes in your workspace is very useful when you want share a change (perhaps a fix for another developer prior to checkin) or have another person review your changes.

    I'll talk more about how works in upcoming posts.  For now, here are some commands you can use to explore shelving in the Dec. CTP.

    Bring up a Visual Studio command prompt (Start -> All Program -> Microsoft Visual Studio 2005 Beta -> Visual Studio Tools -> Visual Studio Command Prompt), cd to a workspace directory with some pending changes, and try out some of the following.  If you need to create a workspace, you can create one with "h workspace /new MyWorkspace /s:yourtfsservername" and then pend some changes.

    To shelve all of your changes in your current workspace, use
        h shelve MyShelvesetName [optional filespecs]

    To unshelve an existing shelveset, use
        h unshelve MyShelvesetName [optional filespecs]

    To shelve the changes and undo them in your workspace, use the /move option with /i (or uncheck "Preserve my changes" in the GUI).  The /move option also deletes pending adds since they get uploaded to the server -- something a plain undo doesn't (and can't) do.
        h shelve /i /move shelvesetname [optional filespecs]

    To delete a shelveset, use the shelve command.
        h shelve /delete shelvesetname

    To see the changes in another user's shelveset, use the status command (when the other user is in the same domain, you should be able to leave that off).
        h status /shelveset:shelvesetname;domain\user

    To see the diffs for a shelveset, use the diff command (great for remote code reviews).
        h diff /shelveset:shelvesetname;domain\user

    You can also see a list of all shelvesets with shelvesets command
        h shelvesets /owner:*

     

  • Buck Hodges

    Problems with large files and the Dec. CTP in Team Foundation Version Control

    • 2 Comments

    If you try, as one person in the Team Foundation newsgroup did, to checkin large files (>200 MB or so), you will reach a point where it fails with a message like "there is not enough storage to complete this command."  That is due to the fact that the Dec. CTP uses the MSPatch library to compress files for upload.  The working set will grow proportionally with the size of the file, and the process will run out of memory.

    The design goal for Team Foundation Version Control is to support up to 2 GB files (size after compression).  We have switched from MSPatch to the new GZip (okay, nothing's written in stone, so keep in mind that it's true while I'm typing) support built into the Whidbey framework.  The result is that the working set grows by only about 5 MB or so regardless of file size, and it's faster for larger files.

    We were really pushing MSPatch into a role for which it was probably not intended.  It's more suited for an environment where minimizing the compressed file is the primary goal while sacrificing run time and memory.

    Using GZip will make life easier for folks like SourceGear who want to write non-Windows clients for Team Foundation.

  • Buck Hodges

    How to delete a team project in the Dec. CTP

    • 2 Comments
    Someone in the newsgroup asked how to delete a team project.  I asked James and he mentioned DeleteTeamProject.exe.
     
    From a Visual Studio command prompt, you can use the following command line app to delete a project.  To get the command prompt, go to Start -> All Programs -> Microsoft Visual Studio 2005 Beta -> Visual Studio Tools -> Visual Studio Command Prompt.
     
    Note that the /domain option is just the name of your Team Foundation server that you see in Team Explorer and is only necessary if you set up more than one Team Foundation server.
     
    Example:
       DeleteTeamProject MyProject
     
    Help:
    DeleteTeamProject.exe
    Usage:
     
    DeleteTeamProject [/q] [/domain:<domainName>] <project name>
     
        [/q]  - Quiet mode.  Do not prompt the user for confirmation.
        [/domain:<domainName>] The name of the domain.  Necessary in multi-domain environments.
        <project name> The name of the project.  Use quotation marks if there are spaces in the name.
     
    Deletes the Portfolio Project from Team System.  After deletion, the project may not be recovered.  Use with caution.  Required permission: DELETE on the project.
    [Update] DeleteTeamProject is not in the path for the command prompt.  The app is in <your drive>:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies.
  • Buck Hodges

    Branching and Merging in the Dec. CTP

    • 2 Comments

    Back in the summer I wrote several posts on branching and merging in Team Foundation Source Control.  They are also relevant for the Dec. CTP if you are interested in this very important part of SCM.

  • Buck Hodges

    Are you looking to convert from ClearCase to Team Foundation?

    • 2 Comments

    The Program Manager for the ClearCase converter, Akash Maheshwari, wants to hear from Clearcase users interested in VSTS.  If you are a ClearCase user, this is your chance to influence the development of the converter.

  • Buck Hodges

    More on setting up a Win2k3 Domain Controller for the December CTP

    • 1 Comments
    In addition to Paul Murphy's post mentioned earlier, Kevin Kelly included a link to the following TechNet article: Installing Windows Server 2003 as a Domain Controller.
  • Buck Hodges

    Checkin policies and the December CTP

    • 1 Comments

    Problem with CleanBuildPolicy in the December CTP

    When you try to configure a new checkin policy, you will get an error regarding the CleanBuildPolicy.  That policy has a problem due to it or one of its dependencies not being properly signed.  You can work around the problem by removing it from the registry by deleting the following key.
        HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Hatteras\Checkin Policies\CleanBuildPolicy

    How to write a checkin policy

    If you would like to write your own checkin policy, you'll want to read Jim Presto's blog.  He has posted information on how to do it along with the code.

    What is the Team Build error dialog about?

    If you get a message dialog about a problem with Team Build, you can safely ignore it.  It's not fully functional in the December CTP.

Page 1 of 1 (9 items)