Buck Hodges

Visual Studio Online, Team Foundation Server, MSDN

Posts
  • 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

    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

    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

    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

    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.

  • 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

    December CTP is available!

    • 5 Comments

    Since my last post ages ago was about a CTP release, I'll start back up again with a post to point to the December CTP.  This one is definitely an improvement over the last one, though it is clear we still have a ways to go.

    You may want to check out the newsgroups for VSTS.  There are a number of people there who post information based on their experiences that may make it easier for you.  This post from June has all the info you need to use the newsgroups.

    There are also some good weblog posts, such as Paul Murphy's post on setting up a domain controller.

    The December CTP is very, very close to what we are using internally now (what Microsoft likes to call dogfooding, which is a term some people take a little too far).  If you can get up and running (yes, you still need two machines), you should find it much more capable than before.

    [Update]  Don't forget to keep an eye out for answers to common problems on the Visual Studio Team System 2005 blog.  Over the next couple of weeks, you should see FAQs and the like as was the case with the September Beta 1 Refresh CTP.

  • Buck Hodges

    VSTS CTP release, including the Team Foundation portion this time

    • 1 Comments

    If you have access to the MSDN downloads or can get a hold of one the DVDs, you can now try out Hatteras and the rest of the Team Foundation along with the rest of Team System.  You'll need several machines to install the CTP release of Team System included in the VS2005 Beta 1 Refresh.

    This release is very close to what we use everyday.  Much of our source code for Team Foundation is stored in a Hatteras server, and we use Currituck for our bug tracking.  Microsoft likes to call it dogfooding, and some people really take the analogy way too far.  But it's certainly a great way for us to find out what it's like to use the product (I'm happy to report that it's been a good experience thus far).

    Having said that, you really should take the warning in the Readme file seriously.

    2.1.1 Community Technology Preview Build Quality

    Visual Studio 2005 Beta 1 Refresh with Visual Studio 2005 Team System is a Community Technology Preview build. These builds are not for everyone. Because our goal is to offer these builds as they are ready, very little effort is put into stabilizing them or ensuring their quality. Typically, our Beta and released products go through a rigorous testing and quality assurance process before they become available. These interim Community Technology Preview builds do not go through this process. It is very likely that removing the build will introduce significant instability to your installed system and may even cause you to need to reformat your drive. Therefore, do not install these builds on machines on which you depend. Specifically, uninstall of Team Foundation Server is not supported in this release.

    Be sure to take a look at Rob Caron's post on the CTP.

  • Buck Hodges

    Handling HTTP response codes in SOAP proxies

    • 4 Comments

    Continuing with the last post on authentication issues with wsdl.exe-generated SOAP proxies, you may need to handle HTTP status codes to provide custom exceptions.  To do this, the SoapHttpClientProtocol class (actually its parent HttpWebClientProtocol) provides a pair of GetWebResponse() methods for derived classes to override.  One method is for synchronous calls and the other for asynchronous.

    The following code shows how to generate a custom exception for the HTTP 401 Unauthorized code.

    using System;
    using System.Net;

    public class MyProxy : WsdlExeGeneratedProxy
    {
       protected override WebRequest GetWebRequest(Uri uri)
       {
          HttpWebRequest request = base.GetWebRequest(uri) as HttpWebRequest;
          request.Headers.Add("accept-language", CultureInfo.CurrentUICulture.Name);
          request.Credentials = m_state.Credentials;
          return request;
       }
       protected override WebResponse GetWebResponse(WebRequest request)
       {
          HttpWebResponse response = base.GetWebResponse(request) as HttpWebResponse;
          ThrowIfUnauthorized(response);
          return response;
       }
       protected override WebResponse GetWebResponse(WebRequest request, IAsyncResult result)
       {
          HttpWebResponse response = base.GetWebResponse(request, result) as HttpWebResponse;
          ThrowIfUnauthorized(response);
          return response;
       }
       private void ThrowIfUnauthorized(HttpWebResponse response)
       {
          // There are cases where response can be null (dropped network connection is one).
          if (response != null && response.StatusCode == HttpStatusCode.Unauthorized)
          {
             throw new UnauthorizedException(response);
          }
       }
       internal SomeObject m_state;
    }
    public class UnauthorizedException : ApplicationException
    {
       public UnauthorizedException(HttpWebResponse response)
       {
          m_response = response;
       }
       internal HttpWebResponse m_response;
    }
  • Buck Hodges

    More on working with SOAP proxies

    • 3 Comments

    In my last post on authentication and SOAP proxies, I mentioned setting the Credentials property on the wsdl.exe-generated proxy object.  Another way to do it and do other things is to override the GetWebRequest() method.

    In the following example, the culture is set in the standard HTTP header to tell the server what culture to use for any formatted data, and the credentials are set directly from some object in the app that holds the credentials.  The advantage of setting the credentials this way is that we don't have to know whether the credentials have changed -- we always get them from the main location before sending each SOAP request.

    internal class MyProxy : WsdlExeGeneratedProxy
    {
        // Customize the web request.
        protected override WebRequest GetWebRequest(Uri uri)
        {
            HttpWebRequest request = base.GetWebRequest(uri) as HttpWebRequest;
            request.Headers.Add("accept-language", CultureInfo.CurrentUICulture.Name);
            request.Credentials = m_state.Credentials;
            return request;
        }
     
        internal SomeObject m_state;
    }

    If you are using Whidbey Beta 1, check out the article on MSDN about the new SOAP proxy generation options, including generating the proxy assembly at build time (rather than the default of generating and building an assembly at runtime) and how to turn on compression.

  • Buck Hodges

    So what runs on Virtual PC 2004?

    • 0 Comments
    I was reading an article comparing Virtual PC 2004 and VMWare 4.5, and they mentioned a link to a site called “What Works and What Doesn't in Microsoft Virtual PC 2004.”  The site currently lists 622 entries.
  • Buck Hodges

    Another Hatteras blogger: Jim Presto

    • 0 Comments
    Jim Presto, a tester on the Hatteras team, has got a blog going.  He starts off with checkin and promises to delve into checkin policies next.  Now, he mentions that “hopefully everyone has the concept of a portfolio project,” but I'm not sure about that.  Perhaps James will post some more about that and how it relates to Hatteras.
  • Buck Hodges

    Using pushd to get to network paths

    • 2 Comments

    A short while ago I saw someone at the office use pushd to cd into a network path.  I've used pushd/popd on Windows for some time, but I never thought to try it on a network path or actually read the help for it.  Pushd will actually map the path to a drive letter automatically and then take you there.  The latter part is expected, but mapping the drive is really cool.  Maybe it should be obvious (how else would the command line do it?), but it wasn't to me.  It's a lot more convenient than “net use“ or anything else that I know of.

    C:\>pushd /?
    Stores the current directory for use by the POPD command, then
    changes to the specified directory.
    PUSHD [path | ..]
      path        Specifies the directory to make the current directory.
    If Command Extensions are enabled the PUSHD command accepts
    network paths in addition to the normal drive letter and path.
    If a network path is specified, PUSHD will create a temporary
    drive letter that points to that specified network resource and
    then change the current drive and directory, using the newly
    defined drive letter.  Temporary drive letters are allocated from
    Z: on down, using the first unused drive letter found.
    
  • Buck Hodges

    Python on .NET just got more support

    • 0 Comments
    Jim Hugunin, who has been writing IronPython, has been hired by Jason Zander (CLR PUM).  He joins the CLR team on Monday, August 2, to work full time on IronPython and generally supporting dynamic/scripting languages on the CLR.  That's really great news for Python on .NET.  Check out the slide from his presentation at OSCON (July 28, 2004).
  • Buck Hodges

    Authentication and SOAP proxies

    • 2 Comments

    My last post discussed authentication in web service calls using HttpWebRequest.  That caused one reader to wonder how this ties back to SOAP requests.

    If you are using wsdl.exe to generate a SOAP proxy class, it derives from System.Web.Services.Protocols.SoapHttpClientProtocol.  That class has a Credentials property. If you want to use the currently logged-in user's credentials, you would assign CredentialCache.DefaultCredentials to the Credentials property.  The same comment about having to assign an instance of NetworkCredential or CredentialCache apply as the proxy uses the HttpWebRequest class.

    [Updated 8/05/2004]  Check out the article on MSDN about the new SOAP proxy generation support in Whidbey Beta 1, including generating the proxy assembly at build time and how to turn on compression.

  • Buck Hodges

    Authentication in web services with HttpWebRequest

    • 20 Comments

    Hatteras has three tiers: client, middle, and data.  The middle tier is an ASP.NET web service on a Windows 2003 Server running IIS 6.  When the client (we use C# for both it and the middle tier) connects to the middle tier, it must authenticate with IIS 6.  Depending upon the IIS configuration, that may be negotiate, NTLM, Kerberos, basic, or digest authentication.  Here's a page on Internet Authentication in .NET.

    NOTE:  The code below uses the .NET 2.0 framework (Visual Studio 2005).

    In order to authenticate, the client must have credentials that the server recognizes as valid.  For Windows Integrated Authentication (comprising NTLM and Kerberos) using the current logged-on user, the client can use CredentialCache.DefaultCredentials.  Here's how it looks in code.

    using System;
    using System.IO;
    using System.Net;
    
    class Creds
    {
        public static void Main(string[] args)
        {
            Uri uri = new Uri(args[0]);
    
            HttpWebRequest req = (HttpWebRequest)WebRequest.Create(uri);
            req.Credentials = CredentialCache.DefaultCredentials;
    
            // Get the response.
            using (HttpWebResponse res = (HttpWebResponse)req.GetResponse())
            {
                StreamReader sr = new StreamReader(res.GetResponseStream());
                Console.WriteLine(sr.ReadToEnd());
            }
        }
    }

    You can find that same type of sample code in MSDN.  However, it gets more interesting if you want to use basic or digest authentication or use credentials other than the current logged-on user.

    One interesting fact is that the HttpWebRequest.Credentials property is of type ICredentials, but it only uses instances of NetworkCredential and CredentialCache.  If you implement ICredentials on your own class that is not one of those two classes, you can assign it to the Credentials property, but HttpWebRequest will silently ignore it.

    To go further, we need to look at the CredentialCache class itself.  This class is used to hold a set of credentials that are associated with hosts and authentication types.  It has two static properties, one of which we used above, that are the "authentication credentials for the current security context in which the application is running," which means the logged-on user in our case.

    The difference is very subtle.  The documentation for DefaultCredentials says, "The ICredentials instance returned by DefaultCredentials cannot be used to view the user name, password, or domain of the current security context."  The instance returned by DefaultNetworkCredentials, being new in .NET 2.0 and of type NetworkCredential, would presumably let you get the user name and domain, but it didn't work for me when I tried it with the following code (UserName returned an empty string).

    Console.WriteLine("User name: " + CredentialCache.DefaultNetworkCredentials.UserName);

    The NetworkCredential class implements both the ICredentials (NetworkCredential GetCredential(Uri uri, String authType)) and ICredentialsByHost (NetworkCredential GetCredential(String host, int port, String authType)) interfaces.  The ICredentialsByHost interface is new in .NET 2.0.

    The CredentialCache class has methods that let you add, get, and remove credentials for particular hosts and authentication types.  Using this class, we can manually construct what setting req.Credentials = CredentialCache.DefaultCredentials accomplished in the original example.

            CredentialCache credCache = new CredentialCache();
            credCache.Add(new Uri("http://localhost"), "Negotiate",
                          CredentialCache.DefaultNetworkCredentials);
            HttpWebRequest req = (HttpWebRequest)WebRequest.Create(uri);
            req.Credentials = credCache;

    The authentication type can also be explicitly specified as "NTLM" and "Kerberos" in separate calls to Add().  This page on authentication schemes explains using Negotiate as follows.

    Negotiates with the client to determine the authentication scheme. If both client and server support Kerberos, it is used; otherwise NTLM is used.

    Let's say you want to work with basic or digest authentication.  The documentation for CredentialsCache.DefaultCredentials and CredentialsCache.DefaultNetworkCredential says that neither will work with basic or digest.  If we add basic to credentials cache, we get a runtime exception.

            credCache.Add(new Uri("http://localhost"), "Basic",
                          CredentialCache.DefaultNetworkCredentials);

    The exception is thrown by the Add() method.

    Unhandled Exception: System.ArgumentException: Default credentials cannot be supplied for the Basic authentication scheme.
    Parameter name: authType
    at System.Net.CredentialCache.Add(Uri uriPrefix, String authType, NetworkCredential cred)

    So, in order to use basic or digest, we must create a NetworkCredential object, which is also what we need to do in order to authenticate as some identity other than the logged-on user.  To do that, we create NetworkCredential object and add it to the CredentialCache as follows.

            credCache.Add(new Uri("http://localhost"), "Basic" /* or "Digest" */,
                          new NetworkCredential("me", "foo", "DOMAIN"));

    Basic authentication sends the password across the wire in plain text.  That's okay for a secure connection, such as one using SSL, and for situations where you don't need much security.  Digest authentication hashes the password along with other data from the server before sending a response over the wire.  It's a significant step up from basic.

    Now we need to have the user name and password to create the NetworkCredential object.  There are two parts to this.  First is prompting the user for the name and password.  The second is storing the information.  For prompting there is the Windows dialog that pops up any time you go to a web site that requires authentication.  That dialog includes a "Remember my password" checkbox.  I don't yet know what the managed API is for that.

    To store and retrieve the information, there is the new managed DPAPI explained by Shawn Farkas in several blog postings.

    [Update 3:44pm]  The Windows dialog used when IE prompts for name and password is created by the CredUIPromptForCredentials() function.  CredUIConfirmCredentials() is used to save credentials that authenticated successfully, if desired.  Duncan Mackenzie's MSDN article Using Credential Management in Windows XP and Windows Server 2003 explains how to use it from .NET.

    [UPDATE 4/10/2006]  I updated the MSDN links that were broken.

  • Buck Hodges

    The story on why Team System is not in Beta 1

    • 2 Comments

    Someone on the newsgroups asked for an official answer on why Team System is not in Whidbey Beta 1.  The short answer is that it's not beta quality, so it didn't belong in a beta.  Keep your eyes open for another CTP release in the next few months.  The current plans for this upcoming CTP are for it to include the server portions of Team System that were not in the May release.

    Rick LaPlante personally replied to the post with the following answer.

    While Paul provides a skeptical, yet possible explanation, as I made the decision, I'll tell you what the real logic was. 

    CTPs (community technology previews) are about getting bits out regularly to customers for early feedback and discussion.  With this release of VS, we are trying to be more open about what we are building and give earlier access to folks to the bits.  By definition, these bits are basically stable builds from our own source trees with minimal additional quality checks built into the process.  They are <NOT> beta quality.  they are interim builds.  As such, it was appropriate to put parts of the Team System into the CTP because we met the quality bar and certainly needed to start getting feedback asap about the feature set and implementation.  As Paul correctly points out (and we've said many times) the Team System is not currently at beta quality and as such we did not include it in Beta 1 of VS.  We will have another CTP in the next few months based on the VS Beta 1 bits that will include the Team System (again not a beta quality build, but expected to be much better than the May CTP) and then follow on with VS Beta 2 which will contain a full, beta quality version of the Team System.

    Hope this answers your question.
    -Rick

  • Buck Hodges

    May CTP to appear again

    • 2 Comments

    The May 2004 CTP that contained Team System (but not Team Foundation, which includes source control and work item tracking) is supposed to be up on MSDN by Monday.  There were a number of requests for it in the newsgroups after it was mistakenly removed from MSDN.

  • Buck Hodges

    Scoble is everywhere

    • 2 Comments

    I got the July issue of Triangle TechJournal and opened it up to find an interview of Robert Scoble by Andy Beal (the interview doesn't appear to be on the web site yet). So even my mail box has been Scobleized.

    Among other things, he mentions taking 7400 pictures over the last 18 months.  Even for digital, that seems like a lot.  I wonder how Longhorn compares to one of the many apps on the market for organizing the pictures (giving both the same metadata of course)?

  • Buck Hodges

    Out for the week

    • 0 Comments
  • Buck Hodges

    TechEd C# presentations

    • 0 Comments
    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

    • 22 Comments

    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

    • 1 Comments

    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

    • 7 Comments

    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
    A
    
    A:
    rock.cs
    scissors.cs
    
    D:\project>h checkin /i
    add A
    
    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
    B
    
    B:
    rock.cs
    scissors.cs
    
    D:\project>h checkin /i
    branch B
    
    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
    $/:
    $A
    $B
    
    $/A:
    rock.cs
    scissors.cs
    
    $/B:
    rock.cs
    scissors.cs
    
    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
    A:
    rock.cs
    
    D:\project>echo new line >> A\rock.cs
    
    D:\project>h delete A\scissors.cs
    A:
    scissors.cs
    
    D:\project>h checkin /i
    A:
    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
    B:
    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
    
Page 22 of 23 (564 items) «1920212223