locked
History Improvements (Phase 1) feedback RRS feed

  • General discussion

  • Regarding the Functional Spec for History Improvements (Phase 1) (updated 13th November 2007):

     

    It would be great if, instead of having seperate labels and changeset tabs/channels, that instead they were filters that could be turned on/off, so that the labels could appear interleaved with the changesets.

     

    When viewing the history of a problem, one of the most common questions is which labels (or builds) the problem occurs in.   This may be a problem that has been in many builds on more than one branch.   Being able to view the labels along with the changesets would make this easier to track.

     

    Sunday, February 3, 2008 11:19 PM

All replies

  •  

    Hello,

     

    Lots of users have requested and interleaved labels view in History, and it is something that we are considering for the next set of History related features we are adding.  One possible problem that we have thought of is the large number of labels that can be applied to an item if frequent builds are performed, for example when using Continuous Integration.  In that case, most files will have a far larger number of labels than changesets, and it is hard to locate the changesets in the interleaved view.  We're working on some options here because for many orgs that don't have many labels this view is very valuable.

     

    Matt

    Monday, February 25, 2008 4:59 PM
  • Many of our development teams are avoiding conversion from ClearCase to TFS solely because of the graphical "Version Tree Browser" in ClearCase. Your history improvements seem to be a non-graphical representation of that data (and actions). Can we add a graphical tree to the functional spec?

     

    If you have access to ClearCase, check out their "Version Tree" view of file history. Each version is shown on a branch line with a "bubble" with labels, tool-tip checkin comments, merge arrows between branches, etc. Clicking a "bubble" allows you to compare to another bubble, checkout/get that version, show the non-graphical history, etc. It is very nice when investigating the lineage of a file.

     

    It seems like the data is all there. These history improvements are completing the picture non-graphically (including user-actions on the items). All that's needed is a visual display UI. Right?

     

    I would love to have all of our teams move over to the TFS server. To this end, I have attempted to create a graphical version tree browser myself - seemed to be quite a task to determine all of the branch, merge, and label history of a given element. I did reach the point where I could obtain, for a given element, all changesets for all branches, and all branch (from and To changesets IDs) and merge (from and to changeset IDs) given a specific version in the current workspace - but I got bogged down trying to track file renames/moves along the history. And I never even started the graphical representation work.

     

    I would love to see this implemented by your team. I know it would sell at least a few copies of the product.

     

    If you don't mind me continuing for a bit....

    I have reached a conclusion as to why some people believe this missing feature is a show-stopper, and others cannot understand why it is needed - this has to do with the branching and merge policy a team follows. Consider if you never branch. What value is looking at a graphical representation of a 'straight-line" development? Zero. Same as a listbox non-graphical list, nearly. Let's say you follow one of the branch and merge best practices - you will have 3 interesting branches and potentially a bunch of seldom-used "version/release" branches. Again, not many branches, not many merges. Who needs graphical representation of dev/main/production? Nice to see at a glance visually when a file went from DEV to MAIN, but not critical. Now consider a team that uses "full branch and merge for every change", i.e., individual developer branches. They need a visual version tree. These are the people who don't want to switch from ClearCase. They are "large" teams (50 or so developers). They always work in parallel. They have adopted what I call "full branch and merge" (branch on every check-out) as a result. They need a visual representation to make sense of the history.

     

    Saturday, April 26, 2008 2:17 AM
  •  

    Thanks for the feedback!  This is really good validation of the need for better visualizations in TFS.  We've heard this request from many customers before, and we are working on a few branch visualization features for our next release.  In the next CTP you'll be able to test out this feature and really tell us what you do and don't like about it.

     

    You are aslo right about the need for visualizations increasing as more complex branching strategies are put into place.  However, because of some of the feautres of TFS (workspaces, changesets, shelvesets), we usually don't recommend the branch per change feature.  Some of the features of TFS should let you get most of what you get from branching for each change without the overhead - atomic changesets should give you the tracability of what changes were introduced together, workspaces allow users to work in an isolated area, and shelvesets give the ability to commit modifications to the server while development is in progress, providing server backup of the changes, the ability for others to view the changes (if necessary), and creating isolation.  That said, there is nothing preventing the ClearCase style workflow in TFS (except maybe the visualizations Smile ). 

     

    Again, thanks for the feedback - it really helps us to understand the pain points of our customers.  Hearing about adoption blockers is also especially interesting. 

     

    Matt

    Monday, April 28, 2008 4:15 PM
  •  

    Maybe I have something set up incorrectly, but it seems like a user with restricted access can add work items to any project in TFS.  Eventually, we would like to move to something like this to automate bug reports from clients, and if we can't keep the client in their own project, we can't use this.  Another item we would like to see is the ability to limit the users displayed in the list for "Assigned To" property.  This could be either administrators or a team foundation server security group (administrators for the project?).  Again, maybe I have something set up incorrect, but I could find any documentation to indicate otherwise.

     

    Thanks!

    Tuesday, April 29, 2008 4:44 PM
  • Hello,

     

    This forum is meant for discussions of new features we're adding in future releases of TFS.  If you post your questions in the WIT forum you'll be able to get the best answers to your questsions. http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=479&SiteID=1

     

    That said, I'm pretty sure you should be able to control who can file bugs in each team project in TFS.  Below are some links that may help:

     

    WIT overview on MSDN - http://msdn2.microsoft.com/en-us/library/ms364081(VS.80).aspx

     Blog post on some of the investments we're making for WIT permissions - http://blogs.msdn.com/teams_wit_tools/archive/2008/01/30/new-permissions-on-work-item-types.aspx

     

    Matt
    Tuesday, April 29, 2008 6:11 PM