bharry's WebLog

PingBack from http://msdnrss.thecoderblogs.com/2008/01/16/new-features-to-understand-branchingmerging/

All the ideas are great...

The view of Scenario 3 would be incredible. Being able to quickly visualize/conceptualize the branch structure I think is important. Something like the proposed view gives a real good snapshot of the folder structure and what's taken place. I like it ;)

When you say "future release" does that mean update or next major version?

thanks !

Number 1 would be excellent, though all of the above features would be usefull to us.

If we could then see the labels inlined with the view in #1, that would be even better.

Any chance of some of these features appearing in a Power Tool ahead of the Rosario release?

Have a look at http://blogs.msdn.com/bharry/archive/2008/01/16/new-features-to-understand-branching-merging

All 4 scenarios will be very helpful to us. And especially the last one. We often have problems merging branches but missing some important changes or discovering major conflicting changes when some critical changes need to be merged and deployed quickly.

Hi

My question might seem a little off-track but i would like to know what tools do you guys use to generate UI mockups and architecture diagrams? The diagrams/mocks are really slick. I would appreciate if you could share the name of the tool so that i can have it bought by our company.

Many Thanks.

Maruf Dolani

Yes! Rosario would be nice. A powertool for Orcas would be even better.

Hmmm. #4 is a hard one. Maybe a bar graph showing unchanged, new, deleted, added, merged and conflicts. Provide a view with both files and # of lines of code. And if you had a method for rating difficulting of a conflict you could do a color gradation from red to yellow in that bar.

I had a red / green color blind colleague look at the graphics (color blindness is a common problem in Norwegian males) and he could distinguish the difference between the bars in your examples. We just adopted Office Communicator internally for instant messaging and I also see that, for example, the "available" green button has a darker core that is visible to the color blind.

thank you.

Paul

another PingBack: http://teamexpand.com/ext/component/option,com_mojo/Itemid,3/

New features are always cool, and a lot more fun to work on and think about than boring stuff like reliability.  But these tools are mission critical to us and we would appreciate some work on the boring bits too.

To be fair, many of the problems I'm having are in the IDE's integration with TFS SCC but those VS guys don't seem to have ever seen a large project so you may have to help them out.

I presume you guys own the SCC explorer.  Give me some help in places where I'm doing things outside the daily development paradigm.  Like importing a new version of a third-party source tree into my SCC forest.  At a minimum I'd like to have a way to flush whatever you call the cache of what TFS thinks I have on my disk.

We're cleaning up a source tree that evolved under VSS to have quite a few "Share" tunnels in it.  In the process we've decided to move one copy of a folder to replace another appearance of (some of) the same information.  We have to commit the deletion of the target folder first, then go in manually and finish deleting the folder on disk, then move the contining instance to its new home and commit that change.  Then I have to repeat all of those steps when I merge those changes into another branch!!!!!

And while we're on the merge topic, I'm seeing a fairly consistent over-estimation of the conflict count in the dialog immediately prior to the manual merge tool.

Beats stone knived and bearskins, I guess.  Keep up the good work.  If we didn't love you we wouldn't be complaining. :-)

Brian - Thanks for this information. Is it possible to get those Visio widgets either as a download package (free) or by placing a partner request (buy)? I would appreciate if you could point me to someone (email/url) who could help me with this.

Thank You.

-Maruf

=======================================

Maruf, The vast majority of our UI mock ups are done in Visio.  Our User Experience Team has created a bunch of Visio widgets for standard VS controls so that we can easily assemble mock ups.  We've debated whether or not/when to try to create a product (Visio add-on) that would make it easy for others to do  the same thing.  Maybe some day, but it's not in the cards soon.

Brian

===================================

I think number 3 sounds best, with number 1 being very useful.

Proposal 3: I see this being useful in cases where I don't know what all the branches might be. We sometimes have to merge urgent hotfix's to a handful of versions to support a couple of clients. Being able to visually see this would be nice.

Proposal 1: I like the drill through. Sometimes I'm looking the change log in one project. I see a merge and want to see what it includes. But I need to actually browse to the originating location of the merge before I can find out what happened.

I would like to see support for one-way (read-only?) branching.  We have a common set of code that is used by a number of teams and we want them to take updates on their schedule.  But we don't want those teams to accidentally change that source code.

Also, it would be nice if the merges could be updated directly from the Solution Explorer or at least from the target folder(s) in the Source Control explorer.

Brian Harry just posted a first look at Branch Visualization. This is the first taste of the next release

Brian published a few screen shots of tools that we are working on right now for the next major release

Brian published a few screen shots of tools that we are working on right now for the next major release

Une des fonctionnalités dont les clients de Team Foundation Server regrettent l'absence est la visualisation

Une des fonctionnalités dont les clients de Team Foundation Server regrettent l'absence est la visualisation

Paul Hacker on RadioTFS is Live. Steven St. Jean on Safe Practices for Team Build and Team Build 2008...

Thank you, Brian, for the response and the opportunity to "dialog".  I don't want to sound ungrateful but our experience with the VS2008 "offline" experience is quite negative.

In particular, during the adoption phase, we've had a need to "go offline" for the purpose of using the "going online" logic to create changesets reflecting a batch of changes that actually took place somewhere / somewhen else.

Apparently the only way to do this is to disconnect our Ethernet cable (physically or logically) and re-open the solution.  In practice I've been doing it by closing the IDE and using the command line.

One of my colleagues, with much VSS experience but without the benefit of four months of exposure to TFS2005 and the Orcas beta, tried to accomplish something similar and gave up in frustration.

As I understand it, the experience improvements won't help somebody who loses their network connection while holding a solution open.  For instance, I've endured the pain of getting a 200-project solution open.  I suspend my laptop and take it home.  Wake it up and continue working.  SCC Integration is broken until I reopen the solution.  And if I manage to get something saved without reopening the solution, returning to the office will not get those changes into source control like it should.

This isn't a scenario that affects very many members of our team but it does affect my boss.

This is the sort of thing that we should have reported much earlier in the CTP cycle but we came to the Orcas party late.

We are hugely happy with the large-project performance of TFS2008.  Much less so for the IDE, of course, but that is somebody else's issue.  Reliability and usability for "everyday developer" scenarios are both quite good.  There are some scenarios in changeset creation and management that have caused us some minor grief but overall we are very happy.

That's a good thing for me: I put my tailfeathers on the line as the new guy in this organization to push for the move :-).  All of the major grief has been related to "unusual" scenarios and, to a large extent, affected only me in my roles as trailblazer and administrator of the source control transition.

In my previous comment I mentioned scenarios in changeset creation and management that cause us "minor grief".  I'm describing the ones I had in mind for completeness.

1) The "pending changes" list is usually but not always up to date.  When you have multiple instances of Visual Studio open this is particularly troublesome.  The grief this causes is that groups of related changes can all too easily end up split across multiple changeset and, if you are in a hurry, these can end up spread over considerable time.  I'm now hitting the "refresh" icon out of habit.

2) On a related note, the way the selection and checkmarks interrelate in the pending changes window for checkin versus undo is very clever.  Too clever by half, perhaps.  I found it quite intuitive but it tends to trip my boss up.  A common source of minor grief in this area is getting almost but not quite all of the changes selected before doing an operation due to scrolling effects.  I suspect this problem will dissappear with experience.

3) The "unshelf" shelfset selection dialog accepts wildcards for the owner name but does not display the owner name in the table of results.  We're using the shelfset feature in change review meetings and it has caused some comical "who's on first" scenes.

4) This isn't really a TFS problem but I don't know who else would attack it.  Changes to solution and project files do not merge well;  A specialized merge tool is needed.  Its development should probably be coupled with an overall configuration management tool; they would share a lot of analysis and visualization code.  If this paragraph ends up in a requirements document, the same tool should support "refactoring" operations on solutions such as combining, splitting, subset extraction, and dependency-graph consistency checking between solutions as well as merging branched changes to one solution.

One final comment while I'm here.  The fact that the Team Foundation Explorer is hosted in the Visual Studo IDE creates an expectation of a level of integration that isn't delivered.  This of course isn't new to VS2008 but we're moving from VSS to all-Orcas tools so we're seeing it now for the first time.  Inconsitencies in "view of the world" that seemed obvious and necessary when using VSS and VC6 now seem dangerous and counterintuitive.

As an outside observer it seems to me you (MS) have been fixing the inconsistencies as they rise above a pain threshold rather than thinking globally about what integration "should" mean.

Just an observation, one that I hope might put some of these issues in perspective.

I think your scenarios are good. These are all tools that would be welcomed.

Another thing that would be HUGELY welcome is the ability to merge between sibbling branches.  Even at just a depth of 1.

I like all four scenarios (the last one especially).

But is there are plans to have a view based on a work items perspective.

I want to explain a scenario we strugle with. Maybe you have a vision for addressing it in the future.

My scenario is a bug is reported that should get fixed in multiple versions (i.e. branches).

It would be really usefull to be able to know in what version (branche) that bug was fixed in.

Currently we create a bug for each version the bug has to be fixed in. Therefore the merge changeset is associate to each bug in each of the appropriate branches.  

This does cause an amount of overhead in our process and bug count.

Here are the reasons we create a bug per version:

1- how to report a bug in multiple versions. Ideally we would select all the version it is applicable to (ideally we would use Found In field). The problem is there is no multiple selection control in WITD (as a side note a workaround it to use a custom control that stores in the selected values as string with some delimiter to parse the selected value. There is one available on codeplex that works well but we have yet to able to create easy reporting for it as each string selection is stored in the tfswarehouse. I hope an out of box solution will be provided in the future)

2- If only one bug is created - all the changesets could be associated to that one bug. The next problem is the verification/testing cycle. How do make sure that fixes are checked in each of the branches? This is the main reason we create a bug per version - traceablity of the testing cycle.  

One idea would be to create a testing task for each version and follow that cycle but that has been perceived as a lot of overhead since who will be responsible to close the parent bug.

Ok back to my question, are there plans on being view the merges/branches from the work item perspective?

With respect to the merging of projects and solutions, I find that manually resolving projects isn't so bad, but solutions are generally far less human-readable. Our de facto solution is to manually resolve the project additions, and then to nuke the TeamFoundationVersionControl section all together so that it can be regenerated.

In any case, a specialized tool would certainly be a treat!

"Could you elaborate on inconsistencies on the "view of the world"?"

Tracking back, this refered to my comment

"[...] The fact that the Team Foundation Explorer is hosted in the Visual Studo IDE creates an expectation of a level of integration that isn't delivered. [...]  Inconsitencies in "view of the world" that seemed obvious and necessary when using VSS and VC6 now seem dangerous and counterintuitive."

Example: when you undo a change to a project file, is it necessary to select the semi-hidden companion file?  I always try to but in any other context it is slaved to the project file transparently.

Better example: when you undo a change to a project file, VS wants to close and reopen the project.  The dialog that prompts for permission to do this still tells you that the file has been changed "outside the environment". No it hasn't, I changed it right here in the Source Contol --- oh, right, that isn't _really_ part of the environment. OK.  But wait -- if it changes due to a "get latest" the IDE reopens it without prompting.

We are in a process of converting several million lines of VC6 code in what will end up being around 300 projects.  Every time I convert a project file I have to jockey around doing manual SCC operations to make up for the "wizard" not being integrated properly with source control.

Converting a VS2005 project is even worse: if you forget to manually check out the .vcproj file before converting it the conversion will fail with a very unhelful error message.

Obviously this scenario was never tried at home base.  I'm curous how projects were typically upgraded to Orcas under TFS among the VSTS team?  I could see porting a much smaller code base outside of source control and then checking it in as a new SCC project but we're putting in a couple of man-years on our port and it would be unthinkable to do that without ongoing SCC.

It's late and I'm not able to call to mind in detail all the other little gotchas I've discovered in this process.  In general the system works pretty well for everyday development tasks. But if you step just a little bit outside that model you're in deep water very quickly.

Oh, here's a strange one: several of us have had .sln files marked as "system", "hidden", or both by "get latest".  Makes it interesting when you can see the file in one view (SCC) but not another (VS open solution dialog, command prompt window).

Once or twice a week I find myself in a situation where some file is marked as checked out but has somehow become read-only on disk and modified in memory.  In that situation you can't get to many of your tools because the IDE wants to save on the way but can't.  I ended up accidentally checking in a rename of our master solution trying to get out of one of these messes without killing the process.

Regarding your recommendation to use folder compare to effect our merge: I'll give it a shot, I failed to discover that capability.  Visualizing the changes, yes.  Creating a changeset from them, no.  The 2005 Power Tools documentation describes the usage of the "online" command for this scenario without mentioning a viable alternative.  Once I worked out one solution I stopped looking for more.

Manually merging our ongoing maintenance changes from VSS with the porting changes in TFS has been the least troublesome part of the project.  That's a testamonial for the merge tool.

Oh, the server: I did my pilot project with TFS2005 Workgroup Edition and have since moved to the RTM Trial Edition of TFS 2008.  We just received the partner packet with the full version.  But both the pilot server and now our production server caught a strange disease where default permissions disappear system-wide.  For instance, trying to "repair" TFS, the installer created a temp folder successfully but then failed out because it couldn't create a file in that folder.  Needless to say, this situation plays heck with the hideously complex internal authentication and authorization architecture of TFS.  We managed to recover SCC in both cases but nothing else works and I haven't been able to figure out how to fix it.  Nor how to prevent it from happening again.

The onset of the condition was not identical between the two servers so this may represent a common reaction of the TFS stack to two different insults.  But none of our other servers have had any occurances like these in living memory.  Too much coincidence for my taste but not a reproducible bug I can report.  God help me, the last thing in the world I want to do is reproduce that monster!

And now we're getting "TFS Server Can't connect to the database" popups at random times.  Sigh.  The pilot server did that occasionally too.  I've got nothing better to do than to try to figure out which layer of the TFS cake is hiding the information I need with which logging mechanism and submit a bug report that will be rejected as unreproducible.

OK, I'm just venting my frustation here and that isn't really fair.  But I do wonder what I'm doing that is so different from what you guys are doing.  I spent days poring over the process guidance documents and have done literally dozens of format-and-install cycles on the servers.  It's not for lack of trying.

"Having wildcard support in the unshelve dialog would be cool, I don't think we support it today.  I just checked and it won't let me type a wild card in the Owner name field on the unshelve dialog.  Is it possible that I misunderstood the context of this issue?"

Hmmm... I haven't tried a general wildcard expression but our team is small enough that we just put in a * and it worked.

Sure enough, x* and *x give an error popup.  But * by itself works great!

That's one bug that's sure to become a feature.

"You are seeing the list of pending changes out of date with Team Explorer 2008?  In the 2008 version, we added a mechanism so that any pending changes that happen/change on on a machine notifies all Team Explorer processes and updates the pending changes.  If you could give me some more specifics in the scenario here, we may have some bugs we should fix."

There's a lag, and with Intellisense and/or builds running it can be a fairly long lag.

It is very difficult without a video recording of the session to determine after the fact whether the orphaned changes were due to synchronization isssues or scrolling/fat-finger issues.  However, in at least one case, I did a checkin, saw an empty "Pending Changes" window, hit "refresh", and had three more changes appear.

It will be a while before a reproducible case emerges for this one, I'm afraid.  But I did have two IDE's running in the case described above.  I've since become much less cavalier about doing that and am working in different VMs instead.  Behavior changes will mask pain points in new software over time.  That's probably why a lot of these things were not detected by internal users.

I think the scenarios outlined are important and the suggested solutions (at least for 1-3) seem reasonable. One scenario I would like to see added is the ability to mark a changeset as "never merge up".  This is important for certain types of branches were you always cherry pick merges change back up to the parent (RIs).  In these cases I would like to be able to mark certain changesets as "never merge up" or something like that. The idea being that if someone else does something dumb like a catch up reverse integration, they will get an error that such marked changesets can't be merged upwards.  Of course, there should be a way to unset this setting on a changeset in case you change your mind.

One other area I have seen that could use some improving is the merging functionality (perhaps this has gotten better in TFS 2008).  I have done merges where there is a conflict on one line and following immediately by several lines of non-conflicting changes. This seems to confuse TFS merge and it includes the non-conflicting lines in the "conflict button". By the way, that "button" in the next is not obvious to folks that merge for the first time.  Anyway I had to manually edit about 80 files that had identical situatios to merge the files.  That kind of sucked.  :-)

I'll second the lack of obviosity for the "conflict button" mechanism.  That and the greyed-out reverse-dependency checkboxes in the solution dependency dialog are both very hard to see on an LCD -- desktop, laptop, or projector -- with default colors and contrast settings.

On the other hand, by far the most common merge conflict is both branches adding new comments to the top of the changelog section of a file.  All I have to do to resolve it is hit the buttons in cronological order and it's done.  Cake!   But one of my colleages failed to discover this: he complained bitterly about all those changelog conflicts until I told him how to handle them.  "Intuitive" is not a context-free concept.

I wish the "navigate conflicts only" checkbox and the window size&pos were sticky for the merge tool.

And the three windows frequently get out of sync, especially when there are long insertions or deletions or when you make manual changes to the merged version.  While there are many hard-to-very-hard problems in the differencing and merging arena I'm fairly sure this isn't one of them.  There could at least be a way to dial in an adjustment to the slaved scrollbars.

An inconsistency: If you attempt to duplicate a solution using "save as" the change that is pended is a rename.  In any office or third party app, save as is understood to create a new, independent document without disturbing the original.  In Orcas' IDE it is indistinguishable from Rename.  I hope this is a bug rather than something somebody decided should happen.  If it is intentional it is broken: the old file is not removed and that prevents Undo on the pending change from working.

Sorry, Japanese Only... 今日は、Team System 関連の私にとっても皆さんにとっても有益なブログをご紹介します。知っている人は知っている(^^;) ブログではないかと思いますが、最近になって

I had a session with a customer where they wanted to know a bit on what is coming in Rosario and 1 or

For maintaining separate releases of our code base, our company uses a branching model that is similar to "Branch per Task" in Chris Birmele's "Branching and Merging Primer" at http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.  This keeps things very simple both conceptually and practically.  For example, one advantage with this model is that it keeps all new development on a single mainline, so developers don't have to keep moving their workspaces to new release lines as they would need to do with the "Branch per Release" model.

The problem with "Branch per Task" is that TFS does not allow you to merge between the task branches (which actually represent separate releases in our environment), because these branches do not have a parent-child relationship with each other.  These types of merges are needed when propagating code fixes from one release branch to another, as well as back into the mainline.  (Incidentally, "Branch by Task" is one of the models that is NOT covered by the "Microsoft Team Foundation Server Branching Guidance" document out on CodePlex.)

Yes, we could use the baseless merge command, but this doesn't have the intelligence of a three-way merge, and we'd rather not tell developers they need to go out to the command line to run the command.  We could also merge all fix changes between the mainline and all affected release branches, but there we'd need to be careful to exclude new development in the mainline that really does not belong in a given release branch.

We've met with several folks at Microsoft about the lack of support for this type of merging, but we have yet to hear whether there will be support for it.  We could write our own merge tool to support this in the meantime, but we'd rather not do that if support for it is coming someday.

One might ask how a genuine three-way merge would even work when merging branches in a "Branch by Task" model.  This is certainly feasible when you consider that each task branch has an ancestor in common with all other task branches.  For example, in Figure 4 in the "Branching and Merging Primer" document, Task A and Task B both have Version 1.1 on the main Development branch in common.

If/when support for this is ever provided, we'd also like support as in Scenario 2, where TFS will tell you all of the branches where a change probably should be made, but specific to our "Branch by Task" model.  Also, it would be preferable to have some sort of enforcement of this, where TFS would at least notify someone when it appears that a code change didn't get propagated into a branch where it probably should have been.

I'd like to second the comment on doing branch per release merging with the ability to do a sibling merge.  I spent a couple of hours thinking I was doing something wrong, read all the TFS documentation and practices, then come to find that it cannot do a merge when I have a code line such as:

1.0->1.1->1.1a

   1.1->2.0

and try to move code from 1.1a to 2.0.  Have to do a baseless merge.  Is there a plan to implement better merging in Rosario?  O/W all the pretty pictures don't do me much good.

Continue from http://dotnet.org.za/willy/archive/2008/05/29/rosario-april-2008-ctp-investigation-part

Over the past few weeks ... sorry for the delays which were caused by events and other distractions q;

クリスマス休暇のころ、私は 3 つの「調査」をお約束しましたが、実際のところこのうち 2 つについてしかまだ説明していませんでした。やっと 3 番目の調査に取りかかることができました。 次回のリリースでは、分岐とマージの管理を簡単にするために設計された新機能を数多くお届けする予定です。現時点では、既にある分岐、分岐間の関連、過去に発生したマージ、まだ発生していないマージなどの把握を容易にするための機能に重点を置きます。この問題に対して、私たちは、現場で実際に直面するシナリオに基づいた分析と、各種のシナリオ用に最適化されたソリューションの構築というアプローチをとりました。これは、分岐とマージを視覚化し、すべての問題