{"id":3731,"date":"2011-09-01T12:28:52","date_gmt":"2011-09-01T12:28:52","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/bharry\/2011\/09\/01\/wrapping-up-tfs-11-version-control-improvements\/"},"modified":"2024-06-11T14:26:15","modified_gmt":"2024-06-11T21:26:15","slug":"wrapping-up-tfs-11-version-control-improvements","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/bharry\/wrapping-up-tfs-11-version-control-improvements\/","title":{"rendered":"Wrapping up TFS 11 Version Control improvements"},"content":{"rendered":"

This is the third post in the series on \u201cDevelopers are Raving Fans\u201d TFS features.\u00a0 The first post was on workspace improvements<\/a>, the second on merging<\/a> and this is kind of a wrap up post that covers the rest of the version control improvements.\u00a0 There\u2019s a few more that are in progress that I\u2019m not quite ready to talk about yet but this should cover the majority of what is left.<\/p>\n

Team Explorer<\/h3>\n

Probably the biggest thing I haven\u2019t talked about yet is the changes to Team Explorer and the Pending Changes window.\u00a0 I\u2019m going to do a full post in the future on the overhaul we have done to Team Explorer so for now I will just focus on a small part of it.\u00a0 The biggest thing you probably need to know is that the Team Explorer tool window is no longer just a simple tree control.\u00a0 It is now a \u201ccanvas\u201d in which we aggregate a number of experiences and allow you to navigate between them.\u00a0 One of the changes we\u2019ve made in the process is to merge the Pending Changes window into the Team Explorer.<\/p>\n

The UI I\u2019m going to show you here is not final \u2013 we\u2019re still tuning and tweaking it (especially the navigation) but it\u2019s getting there.\u00a0 Overall our goal here is to streamline and remove clutter \u2013 in tool window count, complexity and visual overload.\u00a0 Here\u2019s a picture of the new Pending Changes page in Team Explorer and some comments on the changes below.<\/p>\n

\"Image<\/a><\/p>\n

Some things I want to point out:<\/p>\n

    \n
  1. The window has a vertical orientation and shares the space occupied by Solution Explorer by default.<\/li>\n
  2. The look of the of the list of files is much simpler.\u00a0 It\u2019s a reasonably compressed tree view and rather than textually writing the change type, give a more visual indication ([+] for add, [oldfilename] for rename, strikeout for delete, etc).\u00a0 The result is a less cluttered and easier to digest look.\u00a0 Also, for the case of renamed files, I challenge you to find out what it was renamed from in the 2010 version \"Image<\/a><\/li>\n
  3. You\u2019ll notice the checkboxes are now gone.\u00a0 Instead we have \u201cincluded\u201d and \u201cexcluded\u201d changes.\u00a0 You can drag and drop, etc between them.\u00a0 When you check in, only the files in \u201cincluded changes\u201d are included in the check in.\u00a0 The excluded changes also includes the detected changes functionality I talked about in my post on workspaces.<\/li>\n
  4. If you are watching closely, you see that we have an \u201cAdd Work Item by ID\u201d command which was something you couldn\u2019t do in 2010 (you could only pick from a query result) and has been a much requested feature.<\/li>\n
  5. Each section can be expanded or collapse to remove clutter.<\/li>\n
  6. If you have checkin policy violations, that section will show up and if not, you won\u2019t see it \u2013 a nice clutter reduction for those who don\u2019t have policies or violations.<\/li>\n
  7. A checkin notes section will show up if you have checkin notes defined.\u00a0 We don\u2019t have any by default any more so you don\u2019t see them in the pane above.<\/li>\n<\/ol>\n

    As you can see, additional commands are under the \u201cMore\u201d drop down:<\/p>\n

    \"Image<\/a><\/p>\n

    Overall I think the experience around managing pending changes is an improvement.<\/p>\n

    Friendly Names<\/h3>\n

    When we were developing TFS 2005 (oh, it seems so long ago), we built it to show everyone using their domain name (e.g. redmond\\bharry) everywhere in the product.\u00a0 Late in the beta, we got overwhelming feedback that that was a terrible thing for many customers.\u00a0 Many customers have seemingly random sequences of numbers and letter for windows usernames \u2013 so they look like mycompany\\Q27f01.\u00a0 And no one has any idea who that is (maybe not even the person who owns it \"Image<\/a>).\u00a0 It was late enough in the product cycle that we couldn\u2019t make a wholesale change throughout the product so after much going round on feedback, we settled on changing work item tracking to use \u201cfriendly names\u201d (e.g. Brian Harry) and the rest of the product to use domain names (e.g. redmond\\bharry).\u00a0 That quelled the uproar and then somehow, we never found the time to \u201cfinish the job\u201d in TFS 2008 or TFS 2010.\u00a0 Well, we finally have.\u00a0 Now friendly names show up everywhere in the product that a user name shows up.\u00a0 The ultimate driving requirement that made us do this now was that there are no domain names on the internet (Google, facebook, live ID, etc) and in order to show useful names on our hosted service, we had to significantly rejigger how we manage user names.<\/p>\n

    Here\u2019s a screenshot of source control explorer where it\u2019s showing my full name rather than my domain name:<\/p>\n

    \"Image<\/a><\/p>\n

    To ease the transition for people who are so used to domain names (for those that are used to them in version control), I think just about everywhere (in version control) we accept a user name as input, we\u2019ll take either the friendly name or the domain name and do the same thing.<\/p>\n

    Reducing Modality<\/h3>\n

    One of the things that I know no one likes is modal dialog boxes stacked on top of modal dialog boxes on top of yet more modal dialog boxes.\u00a0 In TFS 2010, we had way too much of that.\u00a0 The most serious downside is that the modality causes you to be locked into that part of the UI and unable to access other parts of the UI to investigate related information.\u00a0 Also the stacked dialogs is confusing\/cluttering and we have to introduce new instantiations of commands because you can\u2019t access the main menu\/toolbar, etc.\u00a0 We\u2019ve taken steps to reduce modality around the product.\u00a0 More things show up in document well, in the Team Explorer well, etc.\u00a0 The checkin experience I showed you above in the Team Explorer window is one example (we now use that from many more places in the UI than we used to use the pending changes window).\u00a0 Also having \u201cCompare\u201d use the VS editor in the document well gives a kind of non-modal experience relative to using an external diff tool.\u00a0 Another example I want to talk about is shelvesets.<\/p>\n

    The whole shelveset experience used to be a stacked modal dialog experience.\u00a0 None of it is modal now.\u00a0 If you looked closely at the \u201cMore\u201d context menu I showed in the pending changes section, you saw a \u201cFind Shelvesets\u201d option.\u00a0 This is the analog of the old \u201cUnshelve\u201d button in the 2010 pending changes window.\u00a0 However, rather than launching a modal dialog, it opens a new pane in the Team Explorer window that looks something like this:<\/p>\n

    \"Image<\/a><\/p>\n

    A couple of things to note here:<\/p>\n

      \n
    1. I can still filter by shelveset owner (here it\u2019s filtered to my shelvesets \u2013 that\u2019s the default).\u00a0 I can type \u201cBrian Harry\u201d or \u201credmond\\bharry\u201d and I\u2019ll get the same result.<\/li>\n
    2. I can also filter by text in the shelveset title (the \u201cType here to filter the list\u201d box) and is darn handy for people who keep a lot of shelvesets (and I\u2019ve seen people with dozens and dozens).\u00a0 It\u2019s an incremental \u2013 as you type filter so you only have to type as much as needed to find what you want.<\/li>\n
    3. We provide a nicer way of showing how old the shelveset is rather than just showing the creation date.<\/li>\n
    4. Once I\u2019ve found the shelveset I want, rather than hitting a \u201cDetails\u201d button and getting a modal dialog, double click it and get an in place shelveset details pane, allowing me to operate on the files in the shelveset the same way I would on any other.\u00a0 I\u2019ve included a picture.\u00a0 Note it looks an awful lot like the pending changes window above.\u00a0 As a side note, notice that I\u2019ve configured a checkin note (Localization) and that\u2019s now showing up at the bottom of the pane.\u00a0 I\u2019ve also collapsed the comment section and associated a work item with this shelveset.<\/li>\n<\/ol>\n

      \"Image<\/a><\/p>\n

      Change set details from many places (like history, annotate, etc) will also be non-modal now.<\/p>\n

      Asynchronous Operations<\/h3>\n

      In my first post in this series, I talked about the offline, and responsiveness advantages of local workspaces that don\u2019t have to contact the server to do everything.\u00a0 We\u2019ve also done work around the UI to make things that do have to contact the server more responsive too.\u00a0 We\u2019ve done this by making several more operations async (some things already are \u2013 history, annotate, source control explorer).\u00a0 Some of the asynchronous changes we\u2019ve made rely on the modality changes I talked about a second ago.\u00a0 It\u2019s hard to make waiting for a modal dialog asynchronous \"Image<\/a>\u00a0 Are you going to go start working on something else and then have the modal dialog randomly pop-up at some point in the future?<\/p>\n

      Some examples of asynchronous work we\u2019ve done include:<\/p>\n

        \n
      1. Editing a file is now asynchronous.\u00a0 Local workspaces help decouple us from the server but we\u2019ve also decoupled all the IDE state updating so editing a file really is instantaneous.<\/li>\n
      2. Checking in is now asynchronous \u2013 you can keep on working while your checkin processes.<\/li>\n
      3. Find shelveset is asynchronous.<\/li>\n
      4. Sheveset details and changeset details are asynchronous.<\/li>\n
      5. File compare is asynchronous.<\/li>\n
      6. Other things outside of version control are also asynchronous \u2013 like opening a work item.\u00a0 It used to block the UI.<\/li>\n<\/ol>\n

        There are certain things that have significant interaction with the VS project systems that are hard to make async.&#\n160; Other than that, probably the biggest operation that we haven\u2019t gotten around to making async yet is \u201cGet latest version\u201d.<\/p>\n

        Rollback in the UI<\/h3>\n

        I blogged about this (with screenshots) in my latest Power Tools post<\/a>.\u00a0 We added rollback in the UI in the latest Power Tools for TFS 2010 but we\u2019ve also added it to the TFS 11 product.\u00a0 It\u2019s great to have this long standing request in for good.<\/p>\n

        Restore file modification time<\/h3>\n

        When TFS gets files on to your local disk, it always sets the file modification time to the date\/time that the get operation happened.\u00a0 There are some work practices where this is problematic.\u00a0 Some practices use the date stamp on the file for incremental deployment or other kinds of change management.\u00a0 SourceSafe had 3 options for setting the time stamp on files:<\/p>\n

          \n
        1. The time the file is gotten (this was the default and works very well in concert with make and other similar build dependency trackers).<\/li>\n
        2. The modification time that the file had when it was last edited before checkin.<\/li>\n
        3. The date\/time that the file was checked in.<\/li>\n<\/ol>\n

          TFS 2010 and before only supported option #1.\u00a0 In TFS 11, we have added support for option #3.\u00a0 It can be set on a workspace by workspace basis.\u00a0 We plan to add support for #2 in the future but haven\u2019t gotten there yet.<\/p>\n

          Unix file attributes<\/h3>\n

          Our Team Explorer Everywhere client runs on Unix.\u00a0 One of the things you have to deal with on Unix is the file attributes \u2013 particularly the execute bit.\u00a0 It\u2019s an attribute of a file that really needs to be saved and restored or it messes things up pretty much.\u00a0 TFS 2008 had no support for this kind of thing.\u00a0 In 2010, we added a property system with the goal of applying it in these kinds of scenarios but didn\u2019t get around to adding branching and merging semantics to it so it wasn\u2019t sufficient to carry Unix file attributes.\u00a0 In the meantime the Team Explorer Everywhere team built a work around of storing file attributes in a \u201c.tpattributes\u201d file but it\u2019s an incomplete solution.<\/p>\n

          In TFS 11, we are rounding out the properties mechanism and will be building first class Unix file attributes support.\u00a0 Basically, now you can attach properties to a file in version control and expect them to behave \u201cproperly\u201d across all version control operations.\u00a0 Although Unix file attribute support will be the first feature incarnation on top of this, the #2 scenario for restoring file modification time should be able to follow reasonably quickly on its heels.<\/p>\n

          Properties on Shelvesets<\/h3>\n

          This isn\u2019t going to sound very impressive but in my upcoming post I\u2019m going to talk about some very cool features that build on this.\u00a0 In TFS 2010, we introduced a property system that allows you to tag properties on objects (I talked about this a bit in my Unix file attributes section).\u00a0 However, we didn\u2019t have specific support for properties on shelvesets.\u00a0 In TFS 11, we\u2019ve added that.\u00a0 It\u2019s a general purpose extensibility mechanism.\u00a0 You can attach properties to a shelveset and their access is controlled by the permissions on the shelveset.\u00a0 Also they are deleted when the shelveset is deleted, etc.\u00a0 Give me a week or so and I\u2019ll tell you why this is a very nice feature to have \"Image<\/a><\/p>\n

          Conclusion<\/h3>\n

          That rounds out most of the version control improvements under the \u201cDevelopers are Raving Fans\u201d theme.\u00a0 As I said at the beginning there are a few more thing in the pipe that I\u2019m not ready to commit to yet but what you\u2019ve seen so far is most of it.\u00a0 And it\u2019s quite a lot of stuff \u2013 3 pretty long blog posts to cover it all.\u00a0 And there\u2019s more \u201cRaving Fans\u201d stuff yet to come \u2013 more Team Explorer improvements, build, work item tracking, \u2026\u00a0 I\u2019ll cover the rest in the next few posts.<\/p>\n

          I hope you like what you\u2019ve seen.\u00a0 I can\u2019t wait until I can share the bits for you to try yourself.<\/p>\n

          Brian<\/p>\n","protected":false},"excerpt":{"rendered":"

          This is the third post in the series on \u201cDevelopers are Raving Fans\u201d TFS features.\u00a0 The first post was on workspace improvements, the second on merging and this is kind of a wrap up post that covers the rest of the version control improvements.\u00a0 There\u2019s a few more that are in progress that I\u2019m not […]<\/p>\n","protected":false},"author":244,"featured_media":14617,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[5],"class_list":["post-3731","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-tfs"],"acf":[],"blog_post_summary":"

          This is the third post in the series on \u201cDevelopers are Raving Fans\u201d TFS features.\u00a0 The first post was on workspace improvements, the second on merging and this is kind of a wrap up post that covers the rest of the version control improvements.\u00a0 There\u2019s a few more that are in progress that I\u2019m not […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/posts\/3731","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/users\/244"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/comments?post=3731"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/posts\/3731\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/media\/14617"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/media?parent=3731"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/categories?post=3731"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/bharry\/wp-json\/wp\/v2\/tags?post=3731"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}