Monday, October 12, 2009

Catch 22: The Branch that broke while you were standing on it

Using Team Foundation Server 2008 (TFS) is fantastic in many ways - it’s reliable, flexible and great for team development. It comes with countless of features right out of the box, and there’s even power tools for those that want more.

One of the (i hope) most widely used features of TFS is Branch & Merge (if you’re not familiar with branching strategies, i suggest you read this).

We branch.. constantly.
We merge.. constantly.

One time it got a little too hectic and one very interesting scenario occurred:

What if you want to escape/skip parts of the merge in a FI (forward integration) but still complete the merge?

If you’ve ever faced a situation like that i’m sure you’ve noticed that you can’t simply delete a changeset.. (yes, i know, if you use power tools there’s the rollback, but that’s actually a “destroy” command, not a rollback from what i’ve heard).

Now, to complicate things even more, imagine that scenario taking place from a “baseline” branch..

Picture this:

first

  • 1 – branch from a confused main-branch/baseline where the new dev-base is your hope of restoring the functionality and flexibility
  • 2 – branch a dev-track from your dev-base for a project that –might- become part of your dev-base later on (normal project branching)
  • 3 – start development on dev-branch
  • 4 – oh yes, there’s a “4” even though it’s not in the picture :)
  • 5 – normal FI planned
  • 6 – normal RI planned with new project and code incorporated into dev-base
  • 7 – RI the new and fixed “baseline”

so far so good, nothing –to- major there that will cause more problems than we can handle.. well, that is if you’re not counting the mysterious hidden/forgotten step 4 that we accidentally introduced..

halfway 

  • 1 – same as before
  • 2 – same as before
  • 3 – same as before
  • 4 – we notice that the project that was supposed to exist only in the branched dev-track is in dev base too, and so we delete it from the dev-base and check in, thinking that it’s the way it should be and our dev-base is intact.
  • 5 – time for a normal FI.. but wait! we’ve actually deleted the project in our dev-base, what happens when we try to complete a FI? the dreadful answer to that question is: it gets deleted..! (and that would make the people working on the project in the dev-track very sad.. and most likely very upset too) at this point we realize this step is not possible..
  • 6 – not possible
  • 7 – not possible

It’s quite the annoying situation we’ve ended up in, and it’s quite the mess trying to sort it out.

So, let’s focus on step 5: the FI.

instead of running it automatically we’ll choose the other merge option that allows us to merge specific changesets.

by merging the specific changesets up to, but not including, the changeset(s) containing the delete(s) we know we’re doing a safe merge and that so far all is well.. however, the changeset containing the delete(s) still exist and each time we try to merge it’s still there in the list (and that can create chaos at any given time in the future).

now, applying the same routine as above and merging specific changesets we make sure that any changesets after, but not including, the delete(s) are merged too, thus giving us the merge we set out to complete.

we could stop there.. that would be what we were after.. but there’s still that annoying sting-in-the-back-of-your-head changeset containing the actual delete constantly riding in the list of changes waiting to be merged.

here it comes, the beauty of it all is quite simple:

we use the command-line tf merge /discard option to sort it out.

without diving to much into tfs details the /discard flag tells the merge to keep our local version and not use the server changes (AcceptYours) while still respecting the merge and fully registering the merge as a successful merge in the history – thus removing the dreaded “delete changeset” we never wish to see again..

now, with those changes in place our workflow has returned to a somewhat normal state and we can move thru it with ease:

final

further reading regarding various parts of this article:

How to: Use tf merge /discard?
http://blogs.msdn.com/mohamedg/archive/2009/03/09/how-to-use-tf-merge-discard.aspx

How to: Port a specific changeset?
http://blogs.msdn.com/mohamedg/archive/2009/02/28/how-to-port-a-specific-changeset.aspx

UI Bug: resolving multiple merge conflicts
http://blogs.msdn.com/richardb/archive/2007/06/04/ui-bug-resolving-multiple-merge-conflicts.aspx

Regards,

P.

1 comment:

Dan Galvez said...

Peter,

Thanks for the blog posts. I wanted to turn you on to some of the things we have been working on to bring the great things in TFS to Sitecore Development. I know you are interested in both.

We have a Codeplex project for a process template that we are gearing toward Sitecore development using TFS and a Visual Studio addin that allows you to check Sitecore items into TFS and use Team Build for automated builds and deployments.

Check them out and maybe we can collaborate on the process template.

http://www.hhogdev.com/products/team-development-for-sitecore.aspx

http://hhogdevsitecore.codeplex.com


Dan Galvez
Founder, Managing Partner
dan@hhogdev.com
p. 631.676.2186 x200
c. 516.639.2904

Hedgehog Development, LLC.
4250 Veterans Memorial Highway
Suite 3100 West
Holbrook, NY 11741
http://www.hhogdev.com

Join the Long Island .NET Users Group

Team Development for Sitecore: http://www.hhogdev.com/products/team-development-for-sitecore.aspx
support: support@hhogdev.com
support: http://www.hhogdev.com/support
support: (631) 676-2186 x4250