Buck Hodges

Visual Studio ALM (VSALM, formerly VSTS) - Team Foundation Service/Server (TFS) - MSDN

Posts
  • Buck Hodges

    12 GB CompactFlash card

    • 0 Comments

    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.

    http://www.dpreview.com/news/0405/04052601pretec12gb.asp

  • Buck Hodges

    VSTS Newsgroups

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

    • 10 Comments

    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.

  • Buck Hodges

    Dev303 summary, more blogs

    • 0 Comments

    Thanks to Rob Caron there are good notes on Brian Harry's presentation.

    DEV303 - Visual Studio Team System: Enterprise-Class Source Control and Work Item Tracking

    Kevin Kelly (also in North Carolina) has started a weblog, opening with “Why Work Item Tracking?”  Ask him if they can add make work items blogs. Or maybe all work items should be blog entries, and products would be blogs.  Then you could subscribe to the bug feeds for your stuff.  :-)

    Blogging in DevDiv continues to reach new heights.  With his opening "Hello, World" post, S. "Soma" Somasegar, corporate vice president of the Developer Division at Microsoft Corporation, has provided you a direct link to the top.

  • Buck Hodges

    Brian Harry's weblog

    • 0 Comments

    So Korby's gotten Brian going.  Check out “A little history on me and the Visual Studio Team System” for how we got here.

  • Buck Hodges

    Summary of Doug's Managing Software Configurations presentation

    • 0 Comments

    Korby Parnell, our checked-in tech writer, has posted a great summary of Doug's Managing Software Configurations presentation.  He even included highlights from the Q&A.  Check it out and add your comments.

    Rob Caron posted a picture of Doug in action.

  • Buck Hodges

    Doug Neumann on Software Configuration Management with Burton

    • 0 Comments
    Doug's the program manager for Source Control in Visual Studio 2005 Team Server, and his talk will look at doing details of software configuration management with VSTS. Doug's and Brian's talks cover different ground and will really give you a feel for what we're doing.
    DEVC32 How-To: Managing Software Configurations with Visual Studio 2005
    Wednesday, May 26 2:00 PM- 3:15 PM, Cabana 06
    Speaker(s): Douglas Neumann
    Track(s): Developer Tools and Technologies
    Learn about the strategies for working with and managing configurations of source code with Visual Studio 2005. See how branching, merging, and labeling can be applied to implement several standard SCM practices and help you choose the practice that best fits your software development processes.
  • Buck Hodges

    Visual Studio 2005 Team System (aka Burton)

    • 9 Comments
    The official web site for Visual Studio 2005 Team System is now live, including a Burton blog called AskBurton. I am a developer working on the Burton source control system (Team Foundation), which we code-named Hatteras. Over time I plan to add details about Hatteras and how it works. Here is a good description of Team Foundation from the Team Development page.
    Visual Studio Team Foundation provides integrated source control, work item tracking, reporting, and custom policies that enable your team to efficiently manage change in your software development projects. The components of Team Foundation include work item tracking, source code control, policy support and notifications, and report generating capabilities. By integrating these change management components seamlessly, we unobtrusively inject SCM process and team-specific requirements into the developer’s daily workflow.
    If you are at TechEd, be sure to see presentations by Brian Harry, our product unit manager (PUM), and Doug Neumann, our program manager for Burton source control.
    DEV303 Visual Studio 2005 Enterprise Tools: Enterprise-Class Source Control and Work Item Tracking
    Thursday, May 27 3:15 PM- 4:30 PM, Room 20D
    Speaker(s): Brian Harry
    Track(s): Architecture, Developer Tools and Technologies
    Get an introduction to the new software configuration management system included in the Visual Studio 2005 enterprise tools. See how an integrated and extensible source code control and work item tracking system can boost your team's productivity by significantly streamlining your development processes.
    Hatteras Island, with its famous lighthouse, is part of North Carolina's Outer Banks.
  • Buck Hodges

    Converting a text file from one encoding to another

    • 3 Comments

    The .NET framework handles file encodings very nicely.  Not too long ago, I needed to convert files from one encoding to another for a library that didn't handle the encoding of the original file.  Since someone on an internal alias asked about doing this a couple of weeks ago, I thought it would be useful to post it here.

    The .NET runtime uses Unicode as the encoding for all strings.  The StreamReader and StreamWriter classes in System.IO take an Encoding as a parameter.  So, to convert from one encoding to another, we just need to specify the original encoding and read the file contents into a string followed by writing out the string in the desired encoding.

    The Path class, also in System.IO, provides us with an easy way to create temporary files in the Windows temporary directory.  We can write the results to a temporary file so that if anything goes wrong, the destination file is not overwritten.  Also, it allows the conversion to work when the source and destination are the same file.

    StreamReader allows us to read the source file in blocks so that we don't have any size limitations on the file that need to convert.

    The Main() method below is just a trivial wrapper to call the ConvertFileEncoding()since it wasn't oringally a standalone app.

    // Example: convert test.cs test-conv.cs ascii utf-8

    using System;
    using System.IO;
    using System.Text;
    
    public class Convert
    {
        public static void Main(String[] args)
        {
            // Print a simple usage statement if the number of arguments is incorrect.
            if (args.Length != 4)
            {
                Console.WriteLine("Usage: {0} inputFile outputFile inputEncoding outputEncoding",
                                  Path.GetFileName(Environment.GetCommandLineArgs()[0]));
                Environment.Exit(1);
            }
            
            ConvertFileEncoding(args[0], args[1], Encoding.GetEncoding(args[2]),
                                Encoding.GetEncoding(args[3]));
        }
        
        /// <summary>
        /// Converts a file from one encoding to another.
        /// </summary>
        /// <param name="sourcePath">the file to convert</param>
        /// <param name="destPath">the destination for the converted file</param>
        /// <param name="sourceEncoding">the original file encoding</param>
        /// <param name="destEncoding">the encoding to which the contents should be converted</param>
        public static void ConvertFileEncoding(String sourcePath, String destPath,
                                               Encoding sourceEncoding, Encoding destEncoding)
        {
            // If the destination's parent doesn't exist, create it.
            String parent = Path.GetDirectoryName(Path.GetFullPath(destPath));
            if (!Directory.Exists(parent))
            {
                Directory.CreateDirectory(parent);
            }
            
            // If the source and destination encodings are the same, just copy the file.
            if (sourceEncoding == destEncoding)
            {
                File.Copy(sourcePath, destPath, true);
                return;
            }
    
            // Convert the file.
            String tempName = null;
            try
            {
                tempName = Path.GetTempFileName();
                using (StreamReader sr = new StreamReader(sourcePath, sourceEncoding, false))
                {
                    using (StreamWriter sw = new StreamWriter(tempName, false, destEncoding))
                    {
                        int charsRead;
                        char[] buffer = new char[128 * 1024];
                        while ((charsRead = sr.ReadBlock(buffer, 0, buffer.Length)) > 0)
                        {
                            sw.Write(buffer, 0, charsRead);
                        }
                    }
                }
                File.Delete(destPath);
                File.Move(tempName, destPath);
            }
            finally
            {
                File.Delete(tempName);
            }
        }
    }
    
  • Buck Hodges

    Bill Gates' visit to the University of Illinois

    • 3 Comments

    I didn't realize that Microsoft hires more computer science graduates from U of I than any other school.  It's a great school with a lot of bright people (I don't miss the cold January days, though).

    Bill Gates, the chief software architect for Microsoft, chose Illinois for his first stop on a three-day, five campus tour to promote computer science and engineering to students. Illinois is the only public university that is part of this tour. His February 24th talk, titled “Software breakthroughs: Solving the toughest problems in computer science,” was designed to highlight work being done at Microsoft, universities and research labs around the world.

    If you click on Help->About Internet Explorer, you'll see a couple of references to Illinois.

    Based on NCSA Mosaic. NCSA Mosaic(TM); was developed at the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign.
    Distributed under a licensing agreement with Spyglass, Inc. [Champaign, IL]

  • Buck Hodges

    Download the VC++ Toolkit

    • 4 Comments

    Three weeks ago the Microsoft Visual C++ Toolkit 2003 was made available as a free download.  It's the full optimizing compiler.  That's pretty cool.  It doesn't include the IDE, though people have used it to replace the non-optimizing compiler in the VS Standard edition.

Page 23 of 23 (561 items) «1920212223