Office hours are back!
Have app ideas? Have software development skills? If so, that’s all you need to learn, compete and win! 6 Cities, 100’s of developers and 1000’s of great ideas.
WINDOWS 8 APP FACTOR LEARN | Fun day of “training and auditions” where you will learn what you need to know to take your skills and ideas into a new economy.
WINDOWS 8 APP FACTOR COMPETE | Windows 8 App Factor Compete will provide you with an opportunity to show off your app and hard work to the world and potentially win.
If you don’t have time to attend in person, no big deal, just submit your work of art online to be eligible to win fabulous prizes. Find out what amazing apps are coming out of your community. Watch and see which developers truly have the App Factor, register today!
Special Note: To participate in these sessions, you will need to bring your own computer (laptop preferred). Prep info available at: www.windows8appfactor.com.
We look forward to seeing you there!
(Click on the city for which you’d like to register)
APP FACTOR LEARN
5/31: Bellevue, WA
5/31: San Diego, CA
5/31: San Francisco, CA
6/7: Irvine, CA 6/7: Mountain View, CA
6/13: Tempe, AZ
APP FACTOR COMPETE
6/22: Irvine, CA
6/22: San Francisco, CA
For more information or to register, visit: www.windows8appfactor.com or call 1-877-MSEVENT
Consider this scenario:
In Team Foundation Server 2010 (and previous releases for that matter), support for multiple users editing the same work item at the same time was simple and blunt.
When User A makes a change (based on a now out-of-date version of the work item), he’s presented with the TF237079 error (again, I’m looking at TFS 2010 currently):
This occurs regardless of the field you modify (i.e. if User B changed “Description” and User A changed “Title”, this condition still rears its head).
Dang! Now what? You need to refresh the work item (to suck in the updated version), and lose your proposed changes (well, you have to input them again). The work around for this is simple: If you like to keep work items open (for reference, or whatever) and don’t want to get “blocked” should you decide to make a later change, click the refresh button prior to making your changes. This will reduce the chance that someone else slides in an update before you do.
Team Foundation Server 2012 handles this scenario more smoothly.
Let’s revisit the scenario I listed above. When user A makes his change and clicks “Save”, TFS will check to see if the work item has already changed. If it has, but User B’s change (say to “Description”) doesn’t conflict with User A’s proposed change (say to “Title), it just works (this condition is equivalent to merging in version control when there are differences but no conflicts). TFS will save the User A’s change and refresh the work item for him (so now User A can see his save, as well as the updated field values from User B). Basically, TFS will auto-merge work item updates when different fields are updated (i.e. no stepping on toes).
If the same field is has been updated by User B and User A, now you effectively have a true merge condition. In this case, TFS will give you this message, TF248023:
Look at what the message is saying. It’s not blocking you – it’s warning you that you may step on someone’s toes (i.e. there’s a direct conflict with a field you’re trying to update). If you close this dialog and try to save the work item again, it will allow you to save! Now ideally, you’d take a look at the work item history (per the dialog message) to see check on what changes you’re potentially overwriting before saving; so consider this message as a warning from TFS 2012 saying “I’ll let you save this if you really want to, but don’t say I didn’t tell you so if someone gets mad!”
So again, in previous versions of TFS, the above scenario doesn’t really work. You’re forced to refresh the work item and re-enter your changes. In TFS 2012, if there are no direct field-level conflicts, it works just fine. If there is a direct conflict, you’ll get warned first.
Hope this makes sense!