Buck Hodges

Visual Studio Online, Team Foundation Server, MSDN

Posts
  • Buck Hodges

    More on branching and merging vs. sharing and pinning

    • 12 Comments

    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?

    • 2 Comments

    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

    • 35 Comments

    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

    • 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 (564 items) «1920212223