Buck Hodges

Visual Studio Online, Team Foundation Server, MSDN

June, 2005

Posts
  • Buck Hodges

    CVS compared with Team Foundation Version Control

    • 15 Comments

    In the Team Foundation forum a question was asked regarding CVS compared to Team Foundation Version Control.  Here's what I wrote.

    Of course, Team Foundation is much more than version control since we have integrated work item tracking, reporting, etc.

    I'm biased, of course, and I'm probably leaving stuff out.  I've used CVS in the past, but I wasn't exactly a power user.  Okay, here goes.

    TFS has atomic checkins.  When you check in, it all succeeds or fails.  No changes are committed unless the whole thing succeeds.  CVS does not have this.

    TFS has shelving, and CVS does not.  Shelving is a great way to juggle sets of changes as well as backup changes without checking them in.

    TFS has a SQL database for the server, and CVS does not.  This means that adminstering it uses the same tools famililar to database admins (in beta 2, there is ADAM data not in SQL, but ADAM has been removed -- ignore this comment if it doesn't mean anything to you).

    CVS and TFS both support parallel development.  Everyone checks out and modifies files and resolves conflicts before checking in.  There's no need to grab an exclusive lock.

    CVS does a better job with "offline" mode than TFS in version 1.  It's inherent to CVS because you just modify files and then sync up with the repository before checking in.  When you pend an edit in TFS, you must be able to talk to the server to do it.  We'll be doing a lot more for offline support in the next version.

    TFS branches in path space, which means that branch is a lot like copy.  CVS branches are different.  Branches in TFS can have different permissions (main vs. release branches).

    TFS has checkin policies, and CVS does not.

    TFS supports rename/move, but CVS does not.

    The TFS command line, h.exe, has really nice dialogs for command like checkin, shelve, and resolving conflicts (there's also a /noprompt option to suppress dialogs).  CVS doesn't have that.

    TFS comes with a full GUI, either VS 2005 or the Team Foundation Client (to be renamed Team Explorer).  CVS does not have a GUI itself, though there are several available.

    TFS uses its SQL server for history queries.  CVS doesn't have that support.

    TFS uses SOAP over HTTP (or HTTPS) to communicate with the server.  You don't need to open other ports or tunnel through ssh for remote access as you would for CVS.

    TFS stores files compressed as reverse deltas (diffs from one version to the next).  CVS can't do that.

    CVS and TFS both have branch and merge capabilities, but the changesets used by TFS make it easier to manage.

  • Buck Hodges

    TFS Source Control administration web service

    • 7 Comments

    Have you ever wondered how many files are in your server?  Or workspaces?  Have you wanted to stop a request that was being processed?  Using the administration web service and matching web page for TFS Source Control, you can do exactly that.

    For a beta 2 server, bring up http://localhost:8080/scc/application/admin.asmx in Internet Explorer (either run IE on the application tier or replace localhost with the name of the server).  For the upcoming mid-July CTP server, bring up http://localhost:8080/SourceControl/Application/Administration.asmx (yep, longer name and more capital letters).

    Since we're close to the upcoming mid-July CTP, I'm going use it in the examples.

    When you bring up the web page, you'll see links for the web methods that are available.  You can run these in Internet Explorer, or you can write code in VS 2005 to call the web service methods from an application.  Here is what you'll see.

    Admin

    Team Foundation VersionControl Admin web service

    The following operations are supported. For a formal definition, please review the Service Description.

    If you click on QueryRepositoryInformation and then click the Invoke button, you'll see how many files, workspaces, and so forth that are on the server.  For my current development server, I see the following.

    <?xml version="1.0" encoding="utf-8" ?> 
    <AdminRepositoryInfo xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" UserCount="1" GroupCount="6" WorkspaceCount="2" ShelvesetCount="1" FileCount="2487" FolderCount="27" MaxChangesetID="3" PendingChangeCount="12" xmlns="http://schemas.microsoft.com/TeamFoundation/2005/06/VersionControl/Admin/02" />

    From this you can see that I'm the only user (UserCount = 1).  There are six groups defined (GroupCount = 6).  I have created two workspaces (WorkspaceCount = 2) and one shevleset (ShelvesetCount = 1).  On a beta 2 server, the workspace and shelveset counts are lumped together in the workspace count.  There are currently 2487 files in 27 directories checked into the server (FileCount = 2487 and FolderCount = 27).  I've only checked in twice since the server was created (MaxChangesetID = 3, and the first changeset is always the creation of $/ when the server is installed).

    The last number is the number of pending changes.  It says that there are 12 pending changes on the server (PendingChangeCount = 12).  However, six of those pending changes are in one of my workspaces, and the other six are in the one shelveset I've created.  So, as your users make use of shelving, you'll see your pending change count climb quite a bit.

    You can create a quick shortcut to the repository info page by using the URL you see in IE when you are looking at the XML data.  In this case, it's http://localhost:8080/SourceControl/Application/Administration.asmx/QueryRepositoryInformation.  That gets you the result of clicking the Invoke button without having to click it.

    Clicking on QueryServerInformation will tell you how long your server has been running, the unique ID of the server, and a few other details.

    The ChangeServerState operation allows you to pause or stop the server.  When you click on it, you'll see a newServerState parameter and a comment parameter.  The newServerState values are shown in the SOAP detail below the parameter boxes.  The following lines from that description show what you can enter.

          <newServerState>Stopped or Starting or Running or Paused or Unknown</newServerState>
          <comment>string</comment>
    So, if you enter Paused (be sure to type it with the exact casing you see, or you'll get an error about the value being unknown) for newServerState and type in some text for a comment, the server will be Paused when you click Invoke.  If it succeeds, you'll see a blank window in IE, since we're just using the feature of ASP.NET that allows you to interactively run the web methods, so it doesn't give you anything back since the web method has no response, unlike QueryServerInformation.

    When I paused my server, I put in a comment of "For this demo."  Now, if you'll go back to QueryServerInformation, you'll see that your server is indeed paused (ServerState = Paused and Comment is whatever you typed).

    <?xml version="1.0" encoding="utf-8" ?>
      <AdminServerInfo xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" StartTime="2005-06-29T20:38:33.0581917Z" Uptime="06:49:58.2633623" ServerState="Paused" Comment="For this demo." DateLastStateChange="2005-06-30T03:22:18.3Z" ServerLogState="None" LogComment="Administrative logging not enabled" LogDateLastStateChange="2005-06-29T20:34:06.053Z" RepositoryName="buckhHatteras" RepositoryId="97732cf6-ff08-455c-b0e5-b77ae02844fa" xmlns="http://schemas.microsoft.com/TeamFoundation/2005/06/VersionControl/Admin/02" />

    If you paused your server, now's a good time to go back to ChangeServerState and set newServerState to Running.

    The QueryServerRequests page will show you the currently active server requests.  When I invoke QueryServerRequests, I see the following.

    <?xml version="1.0" encoding="utf-8" ?>
    <ArrayOfAnyType xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/TeamFoundation/2005/06/VersionControl/Admin/02">
      <anyType xsi:type="AdminServerRequest" User="NORTHAMERICA\buckh" ServerProcessID="5978" StartTime="2005-06-30T03:36:11.5461948Z" StopTime="0001-01-01T00:00:00" InProgress="true" ExecutionTime="00:00:00.7343844" WebMethod="Get" RemoteComputerName="192.168.20.105" RemoteComputer="192.168.120.105" RemotePort="2519" />
      <anyType xsi:type="AdminServerRequest" User="NORTHAMERICA\buckh" ServerProcessID="5979" StartTime="2005-06-30T03:36:12.264954Z" StopTime="0001-01-01T00:00:00" InProgress="true" ExecutionTime="00:00:00.0156252" WebMethod="QueryServerRequests" RemoteComputerName="127.0.0.1" RemoteComputer="127.0.0.1" RemotePort="2464" />
      </ArrayOfAnyType>

    I ran "h get" from a command prompt immediately before running QueryServerRequests.  So, there are two requests active.  The second one, WebMethod = QueryServerRequests, is my own requests to see the other requests.  You'll always see at least this entry.  The first one is the result of my execution of "h get" from the command prompt.  The client has called the Get web service on the server to get the latest files into my workspace.

    Earlier I mentioned being able to stop active server requests.  The data returned by QueryServerRequests includes a ServerProcessID.  In the data above, you can see that my Get web service request has ServerProcessID = 5978.

    If you go back to the main Admin web page and click on KillProcess, you can use this ServerProcessID you obtained from QueryServerRequests.  KillProcess takes two parameters, serverProcessID and comment.  For the serverProcessID, enter the ServerProcessID from the QueryServerRequests page for the request you want to stop.  You can also enter a comment to describe why you are doing it.  When you execute the method, the specified request will immediately be stopped, and an error will be returned to the caller.

    The OptimizeDatabase operation removes unreferenced content from the server.  Unreferenced content is data that was uploaded to the server but is not referenced by any shelved change or committed file version.  You don't need to run this, as it's run periodically (once per week, by default I believe).

    With QueryServerInformation and the other methods, you have more information about what's going on with your server and the ability to change it.

  • Buck Hodges

    How to use the TF version control command line from VS 2003 and other environments

    • 3 Comments

    We've had a lot of customer feedback on wanting integration in VS 2003, VB6, etc.  The problem with the VS 2003 environment is that there can only be a single version of the CLR loaded into a process.  VS 2003 loads 1.1.  The TF source control integration requires that the 2.0 CLR be used.  Thus, our VS integration code won't run in VS 2003.  With other environments that don't load a particular CLR, there is the possibility of writing a plugin to provide TF source control integration.

    You can also use Team Foundation Client (which is being renamed Team Explorer) as a stand alone interface to all of Team Foundation running side by side with VS 2003.

    However, if you are writing code and you just want to check out, check in, etc. from with VS 2003, here's a way to do it right now.

    The command line works well and invokes dialogs for commands like checkin, shelve, history, resolve (for conflict resolution), workspace, etc.  These dialogs contain features you would get in the full VS 2005 source control integration (it's a subset of what's in the VS integration).  For example, the checkin dialog when run from the command line gives you the almost the same features as the Pending Checkins window (the shelve and unshelve buttons aren't available in the checkin dialog, but you get pending changes, the ability to compare files, associate or resolve work items, add checkin notes, and evaluate checkin policies).

    The diff command launches the diff viewer.  In beta 2, shelve has a dialog but unshelve does not (unshelve does have the dialog in the the July CTP).  Other commands like checkout (aka edit) and add don’t have any UI and just run.

    You can hook up get, edit, add, delete, checkin, status, diff, workspace, etc. this way.  For some commands, like checkin, status, and shelve, you don’t need to specify an argument (drop the $(ItemPath), which represents the currently open file, and just add the command for those).  The letter in the title after the ampersand becomes the second half of the shortcut so you can run it from the keyboard (Alt T E to edit the current file as shown below)

    Here's the information to put into the External Tools dialog.  After entering the information, click the Add button.  Repeat this for each command you'd like to run.

    Title:             Hat &Edit
    Command:           C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\h.exe
    Arguments:         edit $(ItemPath)
    Initial directory: $(ItemDir)


    The $(ItemPath) will cause it to check out the file that's currently open in VS.  Be sure to check the Use Output Window checkbox so the command line output goes to the VS output window.

    For commands like get, shelve, checkin, and status, you would omit $(ItemPath).

  • Buck Hodges

    Skip the June CTP for Team Foundation

    • 7 Comments

    The June CTP of VS 2005 includes Team Foundation Server.  However, this is not the June CTP discussed in the Team Foundation MSDN forums and elsewhere.  That CTP is now scheduled for July (it was the last week of June, so it didn't change much).  So, anywhere you've see a reference to the June CTP for TFS in the forums, think July CTP.

    The July CTP of TFS will include quite a few performance improvements, protocol changes (which means the just-released June CTP won't communicate properly with the upcoming July CTP of TFS), and nearly all of the code names are gone from assemblies, namespaces, and databases.  We are upgrading our dogfood system to use what we are going to release as a July CTP of TFS, so it's getting more time and effort than a normal CTP.  The June CTP of VS is just a build from June 1 (50601.01).

    So, if you are looking to install the latest Team Foundation Server and see how it has changed since beta 2, wait for the July release.

  • Buck Hodges

    Using baseless merge with converted VSS shared folders

    • 2 Comments

    In this forum thread, http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=18817, a question was asked about using baseless merge with converted VSS shared folders.

    [UPDATE Aug. 22, 2006]  The GUI will not show the relatives of baseless merges, only explicit branch relationships.

    [UPDATE Feb. 6, 2006]  I'm happy to say that baseless merges DO record history in the RC and RTM releases of TFS.  I wouldn't normally go back and edit a post that's this old, but since people will find it using search engines, I want it to reflect the final v1 behavior.

    [UPDATE June 27]  Unfortunately, it doesn't work this way currently.  I was informed this morning by the dev responsible for merge that merge history is no longer recorded for baseless merges.  This means there's currently no way to "re-connect" a branch source and target after import using merge.

    Given that, the only choice is to delete the target directory, check in the deletion, branch the source of the share to the target, and check it in.  With that, you'll have the source and target properly related for merging.

    Hopefully, the baseless merge will record the history before we ship (we're discussing it).

    [UPDATE July 15]  Baseless merge will not record merge history in version 1.

    The VSSConverter doesn't convert shared folders as branches.  Thus, there's no way to merge changes between what the "source" of the converted VSS share and the "target" of the share.  The source and the target have no branch or merge history that connects them.

    This is where the baseless merge comes in.  The purpose of the baseless merge is to establish a merge history between the source and destination.  A baseless merge creates merge history where there was none before.  In a normal dev scenario where you aren't converting from VSS, branching is what establishes the relationship to allow merging changes between the source and target.

    After the conversion is complete, perform a baseless merge between the source and the target of each converted VSS share.  Check in the baseless merge.  Now the source and the target are related through merge history.  As the source (or target) change, the changes can be propagated using the regular (not baseless) merge (command line or the GUI merge wizard).

    So, you only need to do the baseless merge once per shared source and target pair to establish the merge history.

    You can't perform a baseless merge from the GUI.  You must use the command line.  The command sequence looks like the following.

    tf merge /baseless shared-source shared-target

    tf checkin

    After checking in the baseless merge, the source and target are related as though the target had been branched from the source, though the GUI merge wizard will not show that (it queries only for literal branch relationships).

    You can find the command line documentation at http://blogs.msdn.com/buckh/articles/category/9194.aspx.

  • Buck Hodges

    Don't use the June CTP of SQL 2005 with Team Foundation

    • 3 Comments
    It's a question that's come up a lot lately.  The June CTP of SQL 2005 will not work as the SQL backend for the current public releases of Team Foundation.  There have been changes in SQL 2005 that require changes in TFS for it to work.
  • Buck Hodges

    Please send error reports when prompted

    • 1 Comments

    A couple of months ago, Jeff Lucovsky wrote about filing watson reports for Team Foundation.  When you log in as an administrator on the application tier for TFS, you may be greeted with a dialog asking if you would like to report errors to Microsoft.  Likewise, if Visual Studio crashes, you may be asked to report the error to Microsoft.  Please do this.  Specific developers and testers for each of the components of TFS are responsible for making sure that the errors filed through the Microsoft error reporting service (aka Watson reports) are filed as bugs to be fixed.  Each error report contains information about the state of the web service when the error occurred, such as the stack trace and the information passed in the HTTP request, to allow us to diagnose the problem.

    If you look at the event log on the application tier (you can run Event Viewer by entering "eventvwr" in the Run dialog triggered by clicking the Windows' Start button followed by Run...), you will see events logged for errors that are reported using Microsoft error reporting (they'll be reported to us only if you allow them to be sent in the aforementioned dialog).  If you look at the Application log type in Event Viewer, you can spot the events corresponding to reportable errors by looking for events where the Source column is Tfs and the Event column is 9000.  The actual error event usually appears just before it (or it may be separated by a couple of other events).

    You may not run into these errors, but if you do (remember, it's beta software), please consider reporting the errors so that we can fix them.

  • Buck Hodges

    Jeff Beehler's blogging

    • 0 Comments

    Tonight I stumbled across Jeff Beehler's new blog.  So far he's written about our effort to upgrade our dogfood system to new code (we've been using a system based on the beta 2 release), which we'll release as a mid-July CTP.

Page 1 of 1 (8 items)