none
TFS sync issues and questions

    Question

  • I posted this over on Brian Harry's blog and he pointed that I should post this here: http://blogs.msdn.com/bharry/archive/2009/10/08/synchronizing-two-tfs-servers.aspx#comments


    I read on grant's blog about the internal TFS 2010 server (http://blogs.msdn.com/granth/archive/2009/10/19/vsts-pioneer-tfs2010-dogfood-server-upgrading.aspx)

    We have a department TFS server with 30 users on it...and we have a test group ~6 users who want to start using TFS 2010 for testing. We also have BAs that want to start using the new use case modeling/requirement templates.

    We can't do an in-place upgrade to TFS 2010 because we can't touch our production TFS server...we can't do a backup and restore because then the source code and work items will get out of sync very very quickly.

    So we need a way to syncronize our production TFS server with the TFS 2010 Beta2 server we are standing up. We need to sync both ways.

    We've read Willy's posts and followed his diagram:

    http://blogs.msdn.com/willy-peter_schaub/archive/2009/04/06/vsts-rangers-projects-tfs2tfs-project-copy-migration-guidance-initial-thoughts.aspx

    & we read most of his links:

    http://blogs.msdn.com/willy-peter_schaub/archive/2009/10/07/tfs-integration-platform-summary-of-links.aspx

    But when we see labels are not going to be "synchronized" with the tool you're going to be releasing...you might as well not even release the tool.

    http://blogs.msdn.com/willy-peter_schaub/archive/2009/10/14/tfs-migration-platform-why-are-my-labels-not-moving-question-answers-5.aspx

    While I appreciate the numerous blog posting and the work being done on the TFS Integration Platform...I have to be honest that this just feels cobbled together and very very flimsy. [Brain mentions that you guys are using the new tool internally so I'm hoping that I'm wrong...but you guys wrote the tool, you can call the devs on the phone...so I can only suspect that you're hard coding around the specific exceptions that you're running into.]

    For our department to be able to move forward with TFS we the developers NEED good tools from microsoft to handle syncronizing across 2 TFS servers. I'd like to have really sophsicated and reliable tools (with a great WPF UI).

    We expect these to be delivered by Microsoft not on codeplex or sourceforge. [We really want support from Microsoft...I want to get the developer on the phone and work through our issues...my developers can't spend their time re-writing all of TFS's source code management code.]

    As mentioned before....I have to agree that we need to have all the contents of a Team Project "synced"...not just work items and source...but we need documents, reports, areas, iterations, TFS security groups, etc, etc.

    I can't believe we're the only company facing these pains.

    -I forgot to ask another question: Will the new tool sycronize the builds and build quality information? I vaguely remember we ran into an issue where we needed to have the builds and build quality indictaters kept the same between 2 servers and weren't able to come up with a solution.

    A few follow up points, brian mentions that you guys are going to be shipping an alpha on codeplex. In my opinion this sounds like a really BAD idea...because expectations are going to be set that the new alpha version will actually work.

    Please don't post your alpha code, I don't want to face having to hack together your alpha tool. [knowing what Alpha means for our devs...god only know if your Alpha means...and if it does work I'm betting Saturn and Jupiter will have to align while I stand on one leg and balance on a soccer ball]

    Instead I'd rather wait till you guys finally get the tool to truly and honestly and COMPLETELY work....I can keep telling my devs there isn't a solution. But with all of the crappy snake oil solutions in this space I'd rather wait and get my hands on a solution that works.

    Besides seeing how the tfs2tfs migration tool was never updated...I don't want to have to see the alpha version of the new tool get released only to never see the new version get released. I know your going to give me the Microsoft sales pitch that this time is different...but I'll believe it when you have 3 solid releases of the tool out and working.

    Please get the tool right....or don't give us more snake oil....even if you internally can get it working....we aren't microsoft and don't have the time to spend fighting with a tool...either it works or it doesn't work.(period)

    Besides....without the sycronization of labels our source control systems could be irrevocably damaged by your alpha solution(i'm assuming your tool does sync both ways".

    Lastly your "nice to haves" aren't "nice to haves" for our dev shop. We need sycronization of EVERYTHING that comprises a team project. If the solution won't sync everything that is a team project then again your setting us up to have to support another TFS server for the next x years.

    If you can't tell I'm more than a little touchy on this subject: When we moved to TFS 2008 we couldn't upgrade our TFS 2005 server so we tried to use the tfs-to-tfs tool to sync a TFS 2005 server to seperate TFS 2008 server.

    So even today we have to continue to support 3 TFS servers... 2 TFS 2005 servers and 1 TFS 2008 server. I don't want to have to support yet another TFS 2008 server. We really want to move to TFS 2010 but not all of our users can move at the same time...so we have to move selective groups over to the new tool while still keeping the bills paid by the production source code/assets maintained on our current production TFS server.

    Wednesday, October 28, 2009 10:03 PM

Answers

  • Allen,

    Please don't mistake my attempts to try to explain what we are doing with the TFS Integration Platform and the TFS to TFS Connector as trying in any way whatsoever to convince you to try to use it.  You probably shouldn't.  You are almost certainly better off doing exactly what you are doing now if it is working for you, especially in these early releases.

    These exceptionally long forum posts make it hard for others to pick out material of interest.  I would appreciate it if you could mark this post answered and shift follow up questions to separate forum posts.  Feel free to create batches of related questions and post them in one thread, but let's try to spread it out a bit more if you don't mind so that the effort invested in this discussion can be more easily digested by the rest of the community in bite sized chunks.

    Answers:
    1) Microsoft, Microsoft (MCS) and a few partners.

    2) The TFS Version Control adapters will be released as well as a few others.  Since we've moved to a pure adapter based model for both endpoints the TFS adapters are a good sample at the complex end of the spectrum.  We also have a simple proof of concept adapter that will be released and we hope to release another sample that shows how to move document and task list items to/from SharePoint.

    3) No.  TFS group structure and permissions are not synced yet.  The TFS Integration Platform does introduce the notion of a "context sync" phase and the TFS adapters we use in the TFS to TFS Connector do sync some classes of changes, like Work Item Type definitions and Area Path/Iteration Path changes.  Group and security information is a natural future extension.

    4) Yes, global lists are currently synced during the context sync phase.

    5) That shouldn't be a problem.  The system keeps track of the high water mark for the last set of changes synced and will read changes made while one or the other system is unavailable.

    6) We are releasing the source for the TFS Integration Platform and the TFS adapters we are writing to CodePlex to help partners and customers to build bridges to TFS.

    7) I can't think of an alpha where I would have said yes...  No, the alpha release isn't API complete.  We're calling it an alpha because we know there is work left to do and some of that will impact the APIs.  The landing page for the TFS Integration Platform on CodePlex will be clear that the alpha is not intended for production use.  The changes will probably be of the find/replace sort, but there will probably be changes in the APIs ahead of the beta release.  The bar for changes will go up considerably after the beta.

    8) Sure, there will be tests in there.

    9) We can't release TFS binaries to CodePlex so there are a few steps necessary to build the tree as it will be released.  We've got instructions and a script to help you get the tree building.  We'll leave it to you to set up Team Build integration for the version of TFS that you use if you want to go that route.

    10) Yes.

    11) There is no special support in place to handle a baseless merge.

    12) A relatively small internal core team focused broadly on the entire TFS integration tooling space with a satellite of VSTS Ranger led volunteers from our MCS, MVP and partner communities collaborating to help us build the right foundation this time around.

    13) We intend to publish a binary release of the TFS to TFS Connector to MSDN downloads.  That doesn't automatically mean that MSDN support incidents can be used to talk to trained experts in our CSS organization with defined service level agreements.  It is still possible that we'll eventually be able to make that happen, but it is also possible that the support model would be the sort of informal one we use for the TFS Power Tools.

    14) See "snake oil" and the following paragraph in my first response :o)  Please don't get me wrong... you should probably stay away anyhow.  The alpha will have limitations and there is a resource constrained team with priorities that will not be perfectly aligned with the needs of any one customer.  If you have a working solution in your environment, stick with it for now and just watch the TFS Integration Platform and TFS to TFS Connector solution mature to the point where you are comfortable with it.  There is much less risk for your organization down that path.

    15) Yes, we can mix and match TFS endpoints within the limitations of the tool (VC/WIT content only, IDs change, dates change, no labels yet, no groups/permission sync , etc.).  Mixing endpoints may force you to do some advanced configuration to help bridge the feature parity gap between systems, but at a high level, it works fine.

    16) The TFS adapters we have written all work through the TFS object model (OM).  This means that we don't care what version of SQL lies below.

    17) It depends on where the data is stored.  If it is tucked away in a custom field as a string as would happen with most custom controls, then yes, it will get synced.

    18) I'm not sure if I completely understand the question, but if the net effect of running the Teamprise command line tools is that work items and code are changed in a TFS server, then those changes would get synced.  If the question is whether the tool does something specific with the Teamprise clients, the answer would be no.

    19) Deletes are handled fine but destroys are complete and so are not visible to an observer looking through the TFS OM.  Destroys do not get synced.  In a TFS to TFS setting we do have a test tool that we use to very efficiently diff out two TFS systems.  That tool could be used to detect drift caused by destroys, but you would still be generating manual fix up work if you didn't guarantee that a destroy was shown to both systems when content was no longer needed.

    20) Right click on any path in the Source Control Explorer and ask for History.  Click any one of the changesets that you see and ask for details.  That is what gets moved between the two systems.  If conflict resolution in this case means that the devs are doing three way merges prior to delivery of changes, then yes... that would be synced.

    21) No, absolutely not.  The TFS Integration Platform is the wrong tool to use if you need any sort of guarantees around the IDs or the timestamps of the artifacts that are moved.  That is as clear as I can possibly make it.  We don't care what version of SQL TFS uses because we work through the TFS OM but we are bound by the constraints of working at that level in the system and we accept that limitation for the extended reach and breadth that it gives us in this problem setting.

    22) Yes, if you can accept the limitations that come with syncing anything through the TFS OM (IDs change, timestamps change, ...)

    23) The work item type mapping can be a complex thing to configure correctly and the tools we have to help with this task are very limited in the alpha release (e.g., notepad :-).  The simplest configuration is one where you name one of the systems the master in the context sync relationship and you edit things like the work item type definition and area path/iteration path nodes on that system.  That configuration lets you get away with no explicit field or value maps to bridge the gap between types on different systems.

    24) No, cross-domain is not cleanly handled yet.  It is possible to get some cross-domain configurations working, but we haven't yet built a service that understands the identity translation problem.

    25) The TFS adapters try hard to maintain the identity of the person who made the change.  There are special permissions that must be granted to the service account used to run the tools to allow changes on behalf of other people.  If that permission is in place the adapters will first try to make the change in the name of the original user (along with a comment noting that the change was made by the TFS to TFS Connector).  There are some identity resolution problems, like the user no longer being present in AD, that can cause some fallback logic to get invoked.  I believe we raise a conflict if the original user identity cannot be preserved.  We do have a resolution action that can be applied that says that the system should go ahead and check in as the service account with a comment noting the original owner, but the use of that option is a choice you can make.

    26) Branch/merge processing in the alpha release is almost one order of magnitude slower than basic add/edit/delete/etc batch processing times.  It is very chatty.  Outside of performance, branch/merge is where a great deal of complexity in moving changes between systems comes into the picture.  It is possible that you could get a sync relationship like this working but trying to keep the very fine structure of two TFS systems in sync is also sort of asking for trouble.  The guidance we are offering from our own experience and from our experience helping other customers is to go in the opposite direction - try to keep the sync relationship between two systems as simple as possible.  For example, reduce complexity by syncing a single integration branch between servers with no child branches under them and let the fine structure below each branch grow and evolve independently on each server.

    27) I'm glad you like the Power Tools.  Sure, anything that gets checked in is fair game... we don't care how it gets there.

    28)  No, this is another possible extension of what we call our context sync, but check-in policies are not validated or aligned by the tool today.

    29) Yes, the links between changesets and work items is preserved despite the fact that the IDs will change.  The artifacts move through the system at different rates, so links collect in GC-like buckets that are processed at different rates to realize links.  When both endpoints of a link have been moved to a target system the link will be created.  In steady state operation this generally means that a changeset and work item relationship created within one sync cycle will appear to move together.

    30) I don't have a list of PDC attendees handy, but I don't think there is anyone going that will be able to help at this level of detail.

    Bill

    • Marked as answer by Allen.Feinberg Tuesday, December 01, 2009 11:45 PM
    Tuesday, November 10, 2009 9:15 AM

All replies

  • Allen - Brian wasn't the one who directed you to our forum in a follow up, that was my post to his blog (Bill Essary [MSFT]).

    You have clearly had a bad experience with the first generation of the migration tools and you are not alone.  I'm sorry about that.  We clearly have work to do to regain your trust.

    If you don't mind, I would like to avoid starting with a point by point response given the length of the post and instead start by just giving a high level reaction.  I'm happy to address any of the points you make in any order following this post.  I'm just hoping you have the patience to stick with me for a few days to allow this to evolve to a conversation so that we can better understand what factors drove you to three separate instances of TFS stretching back to TFS 2005.

    Snake oil is a little harsh but I do understand where you are coming from.  One problem with the first generation of the tools in addition to quality and stability issues is that they were released without much guidance on when and where they should be used.  I recall clearly the comments of a user who picked up the old version of the TFS migration tool and complained that they spent over a week trying to use it to migrate to TFS 2008.  That poor person didn't have the guidance they needed to understand that they were dealing with an upgrade problem, not a migration/synchronization problem.  That confusion is something we are trying to address directly in this generation of the tools... first by getting the word "migration" out of the TFS Integration Platform name and secondly by working with Willy Schaub and the VSTS Rangers to ensure that we put out solid guidance to help steer users to the right decisions.

    Server upgrade is almost always the best path to a new version of TFS.  We are committed to making the tools the best they can be this time around and we do intend to demonstrate our commitment to the tools by meeting and exceeding your "3 solid releases" bar over time.  Despite that, it is important that anyone who picks up the tools (or drives others to do so) clearly understands the limitations inherent in this approach as well as the fact that there are downstream costs that accrue when establishing a long term relationship between servers.

    The difference between upgrade and migration/synchronization is generally that upgrade is a DB-level, full-fidelity transformation of all assets from a prior version of the system to the new.  Changeset numbers don't change, work item IDs don't change and everything, including build history, is copied to the new system.  Any sort of migration/synchronization tool that is measured against that full-fidelity bar will eventually be found to be inferior.  If you need EVERYTHING and you expect an exact match once the move of data is complete, you need upgrade.  It is as simple as that.  The TFS DB schema is not part of the public interface for the product.  We do not support or recommend direct DB access for any tool, and that includes the entire class of migration/synchronization tools.  Migration and synchronization tools copy assets from one server to the other using the public APIs.  There is a limit to the precision and completeness of any tool built in that way.

    TFS 2010 will make this whole situation better for a few reasons.  One is that Team Project Collections provide a natural and complete isolation boundary for assets.  The problem of extracting "slices" of data from a server at the DB level becomes much easier to solve when the slice itself is a separate DB.  That is what a Team Project Collection in TFS 2010 represents.  Also, the server consolidation scenario that is the inescapable one today when weighing the decision between upgrade and migration/synchronization becomes manageable with TFS 2010.  In your case, for instance, each of the three existing servers could be upgraded to TFS 2010 Team Project Collections when the time is right and the old servers could be retired.  That upgrade process would leave you a full-fidelity, complete copy of all assets with one TFS 2010 server instance to manage.

    There are situations outside of the server consolidation scenario where there is a compelling need for a migration or synchronization solution between two TFS instances.  The situation where a team of 6 people want to move ahead of the rest of the team could be one if the need is deep and the business reasons surrounding the move justify it.  However, part of that decision process must include a balanced assessment of the downstream costs of setting up a new server, establishing a relationship with an existing one, understanding the limits of what moves across that bridge and then managing the relationship between the servers over time.  Internally we have thousands of people on one TFS system and hundreds on another.  We have a compelling business need to keep two separate servers running and to maintain a sync relationship between the two.  Since we know that there is a cost to establish and maintain this relationship it comes as no surprise that events like having files or work items edited simultaneously on both systems will cause some management overhead.  We're doing what we can to drive the cost of management for a sync relationship like this as low as possible and it is inexpensive in the steady state for us today, but the reality is that the connection between the systems is a business critical piece of infrastructure that we have to consider when planning upgrades and generally, when managing our environment.

    Our priority in developing this next generation of the TFS Integration Platform and related tools has been focused on producing high-fidelity copies of source/work item content so that the tree always builds and queries match.  It is also a priority that the tools are robust so that we don't spend an inordinate amount of time "babysitting" and also that they have to have the performance necessary to keep up as changes are made by thousands of users.  You could call the lack of label support in the alpha a form of data loss and I would agree.  It isn't irreversible, but it is a missing feature that is quite important in some environments.  We define the alpha release as the end of a long road where the tool set has been re-architected with our top priorities in mind.  The alpha release should not be used in production and I will make sure that we post that warning and other guidance prominently on the CodePlex site when we release.  For us, the Beta release is our target for the first "go live" release.  We'll have the WPF UI done, label support in place and will have enough tooling necessary to manage and maintain a sync relationship on the solid alpha foundation that we are releasing.  Think of the alpha as the command-line driven engine that works well enough for our large-scale use and Beta as the completion of missing features and the release necessary to make the tools work for most users.

    I'll go back through the other points in your post over the next few days to try to make sure that I address each.  Your thoughts are welcome.

    Thursday, October 29, 2009 8:10 PM
  • Bill thank you for replying to my post and the points I’ve outlined. I sincerely appreciate having a dialog with someone from Microsoft. I know I was very direct about how I see this problem space. I don’t want to get into a debate…honestly I just want Microsoft to listen, hear, and change course. I honestly think you guys are going about releasing your new tool in totally the wrong way.

    I know that I mentioned that most of the tools in this space have been “Snake oil” and here’s why I say that. We had Avanade, Accenture, MCS, and Capgemni all come in and claim that either they had tools to solve this problem or that rolling a solution wouldn’t be that hard. We came to quickly loose respect for each and every one of those firms. None of them were able to fully meet our simple requirement to keep 2 TFS servers in sync for 1 team project. They couldn’t get one-way sync to work for workitems, source control, builds, reports, and documents. We don’t have a complicated TFS setup…we just use the features as they are designed to be used.

    Now I’ll agree with you that a “Server upgrade is almost always the best path to a new version of TFS.”

    But I don’t think you fully realize that for us we can’t just go and upgrade a server all that easily. We have an IT department that won’t let us get near the infrastructure. The IT policy is that any system that is provisioned has to be maintained at its production state for a minimum of 40 months before it can be transitioned to a legacy system. The IT group handles the base OS and SQL server patching but it was a nightmare trying to get TFS 2005 SP1 approved as SP1 had to be audited and approved by the IT department. TFS isn’t well understood by our IT folks so they are reluctant to try and fix it by patching it. We faced the same uphill battle with TFS 2008 SP1.

    Here’s a little more background on our history:

    One of our development teams wanted to use the newer team build CI features along with having our Oracle DBAs being able to checkin via the windows shell extensions so we had to make a decision: get approval to upgrade the TFS 2005 server to TFS 2008, or stand up a new TFS 2008 server for that team and sync over the data. We tried to get approval to upgrade the TFS server but the IT department said that was NOT an option…the server was working and we weren’t out of the 40 month production window.

    So we began our search for a way to synchronize the data. I quickly came to realize that workitem ids, and changeset numbers were quite possibly going to be different between the systems, but we were able to write some scripts that added a bunch of dummy workitems, and a bunch of dummy changesets so that we could get to a known baseline number for the synchronization to start at. Sure we couldn’t always be 100% guaranteed that the changeset comments and workitem ids would be the same…but nothing in life is 100% we just wanted them to be as close as possible.

    I hope this gives you some context about where I’m coming from.

    In thinking about this subject:  4 things crossed my mind and I’d like to give you my thoughts:

    1) I think I read somewhere that you guys have spent the last 9 months building the new tool
    2) You’ve built the new tool to work for thousands of developers
    3) I don’t want to have to pick and choose which features of TFS I have to give up if I’m going to have to use your migration tool.
    4) My developers are extremely crafty…if it’s on codeplex their bound to try it out.

    1) 9 months building a tool – If it’s taking you 9 months to build an ALPHA tool and you’re not syncing everything that is a team project (workitems, source code –labels -branches, builds, documents, reports, security) then either the problem is REALLY REALLY hard for even Microsoft(you guys have the TFS source code right?), and or you are building the tool to handle the internal complexities that only your Microsoft development teams face. But 9 months to build an ALPHA is in incredible.

    2) You guys have thousands of developers. No one and I mean no one except Microsoft, Apple, and Google have THOUSANDS of developers. So it seems pretty obvious that you’re building a tool that’s not geared toward your average developer shop. [I’ve got 30-40 people who’ll access TFS, most companies I know have similar numbers. The challenges you face in building a tool for THOUSANDS for developers are challenges I’ll never face. But the features my 30-40 people need apparently don’t rise that high on your list (like labels, builds, security, reports, documents, etc).]

    3) I like our labels thank you very much…we have an internal build tool that relies on our special labeling strategy. I like our branches too thank you very much…we have an internal auto merge tool that runs every morning and utilizes our labeling infrastructure as well. I like our shelvesets too and we use them for mandatory code reviews. I like our custom build quality workflow change management system too. So if I’m going to have a synchronization tool I don’t want to have to pick and choose what TFS features I’m limited to use. I want my team to be able to have a full TFS feature set on both ends of the synchronization story. By saying you don’t cover feature X, Y, and Z what you’re really telling me is that feature X, Y, and Z aren’t important to your internally teams at Microsoft. Again they aren’t “nice to have” for our shop. Most if not all of the features of TFS are “critical to actually getting Devs jobs done”.  If your tool works for your internal guys…will it work for most average development shops? If not, why are you shipping it?! What potential data could get silo’ed on a TFS server if your tool doesn’t synchronize it across to both TFS servers. [We still have 2 TFS 2005 servers around because our QA tester uploaded 500+ bugs with screenshots, videos, and detailed repro steps that we don’t want to lose…we keep adding to these bugs because there’s no way to move them to another TFS server. Unless you have a suggestion on how to do that?]

    4) My crafty devs. If you post your alpha tool to codeplex one of my developers is going to find it and claim “Eureka! Microsoft solved the sync problem so let’s try it in our environment!” So if you post it even with big red warnings I’m bound to lose a few cycles from 1 or 2 of my developers who want to try out your ALPHA solution…heck they may even want to try to build the label feature(wrong wrong wrong…they need to work on our business apps not fancy source control tools). And even if that doesn’t happen I’m going to be faced with various people in my organization claiming…”blah blah blah Microsoft released a “sync tool” that WILL sync a team project” and I’m going to have to be like “no it doesn’t work for X,Y,Z” whereas today I can just say “there is no way to sync TFS servers. Tough ____.”

    Circling back…I don’t understand the “rush” from you or the team that’s building this synchronization tool. You guys have an ALPHA solution that’s missing gobs of critical features. So why are you wanting to get this out so quickly? Sure I can understand you’ve spent 9 months building something…but I’m sure you’re already getting feedback from select customers on how the current solution works. Work through the pain and missing features with them…don’t dump your ALPHA to the whole world. And when you mentioned that a BETA will be coming to address missing features you sent chills down my spine. a beta?!?!

    Seriously people in my organization are interested in VS 2010 and while they want to learn and dink around with 2010 we’ll still be building on .net 3.5 and 2008 for the next year. From what I’ve read 2010 won’t ship till March which is another 5 months away. Yes I know that Team Project collections are the second coming of Christ…but I need to be sure I’m not going to be setting my team up to fail if we adopt to quickly. And if we’re going to BET the farm on 2010 then I’m going to jump up and down and say “wait for SP1” which should be out in what 8-9 months after 2010 releases so say November of 2010. A full YEAR from now.

    So take a step back and don’t rush out an ALPHA or a BETA over the next 5 months. Who do you think is going to use such a thing…or give you feedback when they realize that so many things are missing? Or what if they do use it in production and then mess up their repository? 

    Instead I STRONGLY suggest putting your hands at the keyboards and building a synchronization tool for your REAL customers…those of us with 30 developers…not thousands…and taking the necessary time to get it right. 100% right.  Give me all of the features of TFS synchronized across to another TFS server.

    TFS isn’t some toy…our livelihood comes from the software that we write and store in TFS.

    You only get 1 first impression and given the bad taste from the TFS2TFS tool I’d rather get a great tool out of the gate…even if I have to wait…then have to consider moving to GIT just to get a better source control system.

    Again thanks for the dialog. But please re-assess your current strategy and don’t give us this ALPHA, BETA stuff….take some time and get it RIGHT. If you are 100% forced to do this ALPHA, BETA thing (who know what insane internal politics and policies you have to deail with)…then I beg you give us VOLUMOUS help files and detailed documentation. Not lousy blog postings or tweets. MSDN style documentation. Surely you can at least do that?

    And if you still insist on this ALPHA and BETA strategy at least put a password on the zip file and then force people to email you for it.

     

    Friday, October 30, 2009 3:03 AM
  • Thanks for taking the time to engage and provide your perspective on the problem.

    Perhaps I can partially ease your concerns by explaining that we do intend to release a binary version of the TFS to TFS Connector tool that we have built on the TFS Integration Platform.  We recognize that most people who land on the CodePlex site come looking for a solution, not a project.  We intend to provide that solution as a high quality binary and we won't release that binary until it is complete.  Now, I think I probably still have a different view of what "complete" means, but in essence, we agree on the need for a high quality binary release with help (and formal support if we can manage to arrange it). 

    I wish we had done a better job of setting expectations early that keeping two TFS servers in sync is not a simple problem.  There were others who made the decision when TFS 2008 came out to split off a lead team to move to a new version of TFS with the expectation that it would be easy to copy data out of the TFS 2005 instance and consolidate servers later.  It wasn't.  That scenario and the scenario where multiple TFS instances sprung up in departments across a company that eventually moved to centralize TFS services did lead partners, MCS and customers alike to the old TFS to TFS Migration Tool looking for relief.  Many failed and I've talked to quite a few of them.

    I sort of hate to bring up Team Project Collections (TPCs) again, but one way you can view them is as a significant investment on the part of the TFS team to address issues that forced people down the migration and synchronization path.  Setting aside the Microsoft-global resource allocation issue, you can see that we do care, but that we are trying to invest in a way that maximizes the benefit to all users and produces the best results.  The migration and synchronization problem is important for a variety of reasons, but we are setting out to solve a slightly different problem with the tools than the one you define.  For instance, our goal with migration and synchronization is not a full-fidelity complete copy of assets where IDs are preserved across systems.  We leave that to upgrade and focus on the highest quality continuous synchronization or migration of the most meaningful assets from any two systems.

    The TFS Integration Platform is an SDK that is intended for partners and developers that would like to build bridges from other systems to TFS.  A big part of the investment we have made has gone into something that is more or less orthogonal to the TFS to TFS Connector - making it simple to write a simple adapter.  We've had one early adopter create an adapter for another version control system in a short period of time where other partners who had built on the old TFS Migration and Synchronization Toolkit had failed, so the early signs are good that this investment will help that part of the community.

    Thanks for the additional background on the path that led you here.  I've worked with different IT shops and know that many have rigid constraints in place that they rely upon to maintain order in their own way.  The 40 month production window in your environment is just one example of the forces that tend to pin TFS instances to an older version.  The release of a new version of TFS will tend to drive an evaluation of the business needs and impact of upgrade.  You made the choice, as did others, to attempt to resolve the conflicting requirements by effectively splitting the original server.  We could have served you better by having clearer guidance in place to help you better understand the downstream costs of that decision.

    One thing that is important to note is that TFS has a very high degree of forward and backward compatibility with clients.  You mentioned the Windows Shell Extensions Power Tool and the version of the .NET framework and Visual Studio version as some of the factors that influenced your decision to stand up a new server and invest in trying to keep it in sync with the older server.  Generally, those client-side choices shouldn't carry much weight in that TFS decision process because the client and server versions do not have to match.  Let those who want to use VS 2008 against a TFS 2005 server do that or keep your source that is built with the VS 2005 tools on a TFS 2010 Beta 2 server.  It all works.

    Ok, on to the specifics:

    1) 9 months building a tool...

    Think of it as time spent building the TFS Integration Platform, not the TFS to TFS Connector.  We did both, but the former is where we invested most of our energy.

    2) Thousands of developers...

    We care deeply about the features your team of 30-40 people need.  The only aspect that the thousands of developers added to what we did was to intensify our focus on content correctness (making sure the tree always builds) and performance.  You needed those features too.  The first thing our modest-sized team did when picking up the project was to try to move to a different TFS system and set up a sync relationship with the main TFS server we use.  It took 26 hours to move a relatively small amount of code and there were holes in the tree that broke the build.  We've fixed that.

    3) I like our labels...

    I like your labels too, and your shelvesets and every other feature you use.  When we think about and create sync relationships between systems, we do it with an understanding of the limits of what moves through that pipe.  That does mean that we do not build a reliance on code review processes that hinge on shelvesets that need to move from one server to the other.  Perhaps one day that full-fidelity multi-master sync will happen, but that isn't an investment that many of our customers are asking us to make.

    The way we would recommend that you get rid of the 2x TFS 2005 servers with 500+ bugs each is to deploy TFS 2010 (Beta 2) and then upgrade each to create new Team Project Collections.

    4) My crafty devs...

    How about if I am the one who says "no, it doesn't work for X, Y or Z"?  When those crafty devs come to your door, fire a link to this forum back at them.

    There is no rush but there are competing demands.  We need to release the alpha for the TFS Integration Platform and that means we will also be publishing an alpha of the TFS to TFS Connector solution.  We have a bunch of guidance, documentation, and other material that we will release at the same time to try to meet our obligation to provide direction to users on when and where the tools should be used and what to expect once that decision is made.

    Friday, October 30, 2009 9:48 PM
  • Bill,
     I posted this thread on our internal sharepoint dev wiki and asked my developers for questions about the TFS Integration Platform/connector. I hope you don’t mind answering a few questions...they sure caused my noodle to have to rethink about the implications of “sync”.

    I’ve cleaned up their questions and I’ve posted them below.

    I’m personally looking forward to getting answers to many/most/all of these questions. Even if the answer is "no" this tool doesn't/can't solve that problem.

    At least we'll have context around what you've built. ;) 

    1) What customers have been successful in using/building on top of the new TFS Integration Platform? Can you name 3? If you can’t publically identify 3 can you provide 3 teams at Microsoft that would write up their experiences with the new tool/platform? If you can’t provide references could you get the internal team that’s writing the tool to go on the TFS podcast TFS Rocks and explain their experiences/limitations?

    2) It’s been mentioned that this integration platform is partially an SDK, in the Visual Studio SDK there is a sample/referenced database based version control example. Will the TFS Integration Platform use this reference application and demonstrate how to sync changes over to TFS? If not that referenced sample then will the SDK include a real rich sample migration application from “some” platform to TFS. [Mainly I’m thinking of Pvcs, VSS, CVS, ClearCase, GIT, Subversion, Vault, insert FOO repository]

    3) We have TFS security groups setup on our branches in TFS, if we go ahead and use the TFS Integration Platform connector will security changes on 1 TFS server be mirrored over to the “synced” TFS server?

    4) We use custom controls that utilize and update global lists will the TFS Integration Platform connector be capable of keeping global lists in sync?

    5) Our IT staff has our TFS servers on different patching schedules so that on Tuesday nights we patch one TFS server with windows patches and we patch the other TFS server on Thursday nights. How would the TFS Integration Platform connector handle catching up when one of the nodes in the sync relationship goes offline and then comes back online?

    6) This alpha, beta release is quite surprising from Microsoft I thought MS Developer Division had rigid quality gates on their software see this http://howsoftwareisbuilt.com/2008/03/04/interview-with-mark-osborne-developer-division-architect-microsoft/ Why is the team that’s developing the TFS Integration Platform/connector solution going about a different development process? What are the benefits for this alpha beta model...i just don't see them?

    7) Will the ALPHA release of the TFS Integration Platform be API complete? In other words if we want to start building off of the alpha solution what kind of guarantee would we have that Microsoft isn’t  going to go and massively change the apis when they get to the 1.0 version.(I'm all for agility...but please don't be like google.)

    8) Will Microsoft be publishing the unit tests and functional tests when they release the source code of the alpha version? If not, why not?

    9) Will MS be publishing the guide/steps that they use internally to have Team Build build the TFS Integration Platform and connector? We’d want to able to easily take MS’s solution and extend it on our own.

    10) Does the team that’s actually building the TFS Integration Platform connector work on 2 separate TFS servers and use the connector to keep them in “sync”. Microsoft claims to dog food their stuff is the team writing the connector dogfooding this tool while they are writing it(day to day devlopment synced arcoss 2 servers...i doubt that you have thousands of developers writing this tool)? If not why not?

    11) We run into the scenario quite frequently of needing to do baseless merges between branches, does the TFS Integration Platform connector support and “sync” baseless merges?

    12) Who’s actually building the TFS Integration Platform, Microsoft? A bunch of MVPs? A bunch of internal developers at MS for some internal teams? A college intern?

    13) Will this connector be published to MSDN downloads so we can use support cases that come with our MSDN subscriptions when we run into issues? If not, why not?

    14) The TFS2TFS connector languished for 2 years without any “official” updates from MS, what commitment does MS have to support this new platform? IE…what does the release schedule look like? Or is this a one off kind of a thing. (if it’s one off again we’ll be staying far far away...see the TFS2TFS snake oil)

    15) We have a mixture of 2005, 2005wSp1, 2008, and 2008wSP1, and soon TFS 2010 B2, then probably TFS 2010 RTM will the TFS Integration Platform connector “sync” between these multiple configurations? I think it's next to impossible...but have you guys cracked this giagantic problem for all versions of TFS or just 2008wSp1 and 2010?

    16)  We also have SQL 2005, SQL 2005 SP2, SQL 2005 SP3, SQL 2008, SQL 2008 SP1 setups with our TFS infrastructure will we run into issues with the TFS Integration Platform connector if the SQL platforms are different?

    17) We have a special workitem control that allows inline queries to be created on work items, will the TFS Integration Platform connector “sync” changes made to the queries that are updated on workitem forms?

    18) We have several teamprise clients for our java development and we use the teamprise command line tool to update work items and checkin/checkout code/branch etc…will the TFS Integration Platform connector support “syncing” from these tools across 2 TFS servers?

    19) We run into the need to destroy source code files, branches, and work items definitions on a routine basis, will the TFS Integration Platform connector support “syncing” these destory changes across 2 TFS servers?

    20) We use Beyond compare pro for our developers to do their conflict resolution…will the TFS Integration Platform support “syncing” resolutions across 2 TFS servers?

    21) I understand the changeset numbers and work item numbers may/(probably will) be different between the 2 TFS servers. We’ve written custom tools that rely on the transaction date/time of the changesets and the itemspecs will the TFS Integration Platform connector ensure that the timestamps of the history are the same on both TFS servers(from the point of "sync" forward"?

    22) 2010 Project collections are a huge +….they are supposed to be completely separated….but could we use the TFS Integration Platform connector to “synchronize” across the TPC boundary?

    23) We use the scrum for team system process template will the TFS Integration Platform connector work across 2 TFS servers with the same version of the scrum for team system process installed?

    24) Will the TFS Integration Platform connector work if the 2 TFS servers are in different domains? What if we use local machine accounts on both TFS servers(we have .dev and .test domains that have the seperated TFS servers in them)?

    25) Will the TFS Integration Platform connector ensure that the userid of the person creating the workitems/checkins will be the same across both TFS servers…or is it somekind of weird “created by TFS Integration Platform connector account” that is used?

    26)  We have an in house tool that runs every night and takes the shelvesets the developers use/create and creates private branches for them for each shelveset(i didn't say our own internal tools weren't hacky)…this can result in dozens of branching operations happening in short order…can the TFS Integration Platform connector handle many branching operations?

    27) We use the powertools (love 'em) rollback command [Tfpt rollback] to undo a change that we've actually checked into TFS. This undo command basically goes to the changeset before the "errant" changeset and re-applies that previous changeset as the latest. Will the TFS Integration Platform connector handle rollbacks done on both TFS servers? (maybe not the same file being simulanetously rolled back...but seperate rollback operations)

    28) We use the checkin policies and have written a few of our own policies will the sync tool ensure that on both ends of the sycronization the same checkin policies will be applied?

    29) Our internal merge and branch tool relies on the changeset to workitem link to consistently be maintained....will the TFS Integration Platform ensure that the changeset to workitem linking wil be the same (even if different workitem ids, or changeset ids)?

    30) We have 2 devs going to PDC next week, who from MS will be at PDC that these guys can speak with who will be familiar with the deep guts of the TFS Integration Platform/connector?

    Saturday, November 07, 2009 1:54 AM
  • Allen,

    Please don't mistake my attempts to try to explain what we are doing with the TFS Integration Platform and the TFS to TFS Connector as trying in any way whatsoever to convince you to try to use it.  You probably shouldn't.  You are almost certainly better off doing exactly what you are doing now if it is working for you, especially in these early releases.

    These exceptionally long forum posts make it hard for others to pick out material of interest.  I would appreciate it if you could mark this post answered and shift follow up questions to separate forum posts.  Feel free to create batches of related questions and post them in one thread, but let's try to spread it out a bit more if you don't mind so that the effort invested in this discussion can be more easily digested by the rest of the community in bite sized chunks.

    Answers:
    1) Microsoft, Microsoft (MCS) and a few partners.

    2) The TFS Version Control adapters will be released as well as a few others.  Since we've moved to a pure adapter based model for both endpoints the TFS adapters are a good sample at the complex end of the spectrum.  We also have a simple proof of concept adapter that will be released and we hope to release another sample that shows how to move document and task list items to/from SharePoint.

    3) No.  TFS group structure and permissions are not synced yet.  The TFS Integration Platform does introduce the notion of a "context sync" phase and the TFS adapters we use in the TFS to TFS Connector do sync some classes of changes, like Work Item Type definitions and Area Path/Iteration Path changes.  Group and security information is a natural future extension.

    4) Yes, global lists are currently synced during the context sync phase.

    5) That shouldn't be a problem.  The system keeps track of the high water mark for the last set of changes synced and will read changes made while one or the other system is unavailable.

    6) We are releasing the source for the TFS Integration Platform and the TFS adapters we are writing to CodePlex to help partners and customers to build bridges to TFS.

    7) I can't think of an alpha where I would have said yes...  No, the alpha release isn't API complete.  We're calling it an alpha because we know there is work left to do and some of that will impact the APIs.  The landing page for the TFS Integration Platform on CodePlex will be clear that the alpha is not intended for production use.  The changes will probably be of the find/replace sort, but there will probably be changes in the APIs ahead of the beta release.  The bar for changes will go up considerably after the beta.

    8) Sure, there will be tests in there.

    9) We can't release TFS binaries to CodePlex so there are a few steps necessary to build the tree as it will be released.  We've got instructions and a script to help you get the tree building.  We'll leave it to you to set up Team Build integration for the version of TFS that you use if you want to go that route.

    10) Yes.

    11) There is no special support in place to handle a baseless merge.

    12) A relatively small internal core team focused broadly on the entire TFS integration tooling space with a satellite of VSTS Ranger led volunteers from our MCS, MVP and partner communities collaborating to help us build the right foundation this time around.

    13) We intend to publish a binary release of the TFS to TFS Connector to MSDN downloads.  That doesn't automatically mean that MSDN support incidents can be used to talk to trained experts in our CSS organization with defined service level agreements.  It is still possible that we'll eventually be able to make that happen, but it is also possible that the support model would be the sort of informal one we use for the TFS Power Tools.

    14) See "snake oil" and the following paragraph in my first response :o)  Please don't get me wrong... you should probably stay away anyhow.  The alpha will have limitations and there is a resource constrained team with priorities that will not be perfectly aligned with the needs of any one customer.  If you have a working solution in your environment, stick with it for now and just watch the TFS Integration Platform and TFS to TFS Connector solution mature to the point where you are comfortable with it.  There is much less risk for your organization down that path.

    15) Yes, we can mix and match TFS endpoints within the limitations of the tool (VC/WIT content only, IDs change, dates change, no labels yet, no groups/permission sync , etc.).  Mixing endpoints may force you to do some advanced configuration to help bridge the feature parity gap between systems, but at a high level, it works fine.

    16) The TFS adapters we have written all work through the TFS object model (OM).  This means that we don't care what version of SQL lies below.

    17) It depends on where the data is stored.  If it is tucked away in a custom field as a string as would happen with most custom controls, then yes, it will get synced.

    18) I'm not sure if I completely understand the question, but if the net effect of running the Teamprise command line tools is that work items and code are changed in a TFS server, then those changes would get synced.  If the question is whether the tool does something specific with the Teamprise clients, the answer would be no.

    19) Deletes are handled fine but destroys are complete and so are not visible to an observer looking through the TFS OM.  Destroys do not get synced.  In a TFS to TFS setting we do have a test tool that we use to very efficiently diff out two TFS systems.  That tool could be used to detect drift caused by destroys, but you would still be generating manual fix up work if you didn't guarantee that a destroy was shown to both systems when content was no longer needed.

    20) Right click on any path in the Source Control Explorer and ask for History.  Click any one of the changesets that you see and ask for details.  That is what gets moved between the two systems.  If conflict resolution in this case means that the devs are doing three way merges prior to delivery of changes, then yes... that would be synced.

    21) No, absolutely not.  The TFS Integration Platform is the wrong tool to use if you need any sort of guarantees around the IDs or the timestamps of the artifacts that are moved.  That is as clear as I can possibly make it.  We don't care what version of SQL TFS uses because we work through the TFS OM but we are bound by the constraints of working at that level in the system and we accept that limitation for the extended reach and breadth that it gives us in this problem setting.

    22) Yes, if you can accept the limitations that come with syncing anything through the TFS OM (IDs change, timestamps change, ...)

    23) The work item type mapping can be a complex thing to configure correctly and the tools we have to help with this task are very limited in the alpha release (e.g., notepad :-).  The simplest configuration is one where you name one of the systems the master in the context sync relationship and you edit things like the work item type definition and area path/iteration path nodes on that system.  That configuration lets you get away with no explicit field or value maps to bridge the gap between types on different systems.

    24) No, cross-domain is not cleanly handled yet.  It is possible to get some cross-domain configurations working, but we haven't yet built a service that understands the identity translation problem.

    25) The TFS adapters try hard to maintain the identity of the person who made the change.  There are special permissions that must be granted to the service account used to run the tools to allow changes on behalf of other people.  If that permission is in place the adapters will first try to make the change in the name of the original user (along with a comment noting that the change was made by the TFS to TFS Connector).  There are some identity resolution problems, like the user no longer being present in AD, that can cause some fallback logic to get invoked.  I believe we raise a conflict if the original user identity cannot be preserved.  We do have a resolution action that can be applied that says that the system should go ahead and check in as the service account with a comment noting the original owner, but the use of that option is a choice you can make.

    26) Branch/merge processing in the alpha release is almost one order of magnitude slower than basic add/edit/delete/etc batch processing times.  It is very chatty.  Outside of performance, branch/merge is where a great deal of complexity in moving changes between systems comes into the picture.  It is possible that you could get a sync relationship like this working but trying to keep the very fine structure of two TFS systems in sync is also sort of asking for trouble.  The guidance we are offering from our own experience and from our experience helping other customers is to go in the opposite direction - try to keep the sync relationship between two systems as simple as possible.  For example, reduce complexity by syncing a single integration branch between servers with no child branches under them and let the fine structure below each branch grow and evolve independently on each server.

    27) I'm glad you like the Power Tools.  Sure, anything that gets checked in is fair game... we don't care how it gets there.

    28)  No, this is another possible extension of what we call our context sync, but check-in policies are not validated or aligned by the tool today.

    29) Yes, the links between changesets and work items is preserved despite the fact that the IDs will change.  The artifacts move through the system at different rates, so links collect in GC-like buckets that are processed at different rates to realize links.  When both endpoints of a link have been moved to a target system the link will be created.  In steady state operation this generally means that a changeset and work item relationship created within one sync cycle will appear to move together.

    30) I don't have a list of PDC attendees handy, but I don't think there is anyone going that will be able to help at this level of detail.

    Bill

    • Marked as answer by Allen.Feinberg Tuesday, December 01, 2009 11:45 PM
    Tuesday, November 10, 2009 9:15 AM
  • Bill,
        Just getting back to looking at this thread. I'll mark your last post as the answer.

    I had one of my guys pull down your alpha code off of codeplex and take a look at it and try to use it.

    His feedback to me is that at this point was that this new tool and the source code along with it are not in a state that we can reliably build ontop of, and that we should NOT even attempt to use this tool to synchronize to our Beta2 TFS server. 

    We still believe a robust and reliable solution is needed....and we hope that in time we'll see something be delivered by Microsoft. Hopefully a tool that has baseless merge support, security/user support, label support, and cross domain support. I don't want to hazard a guess on how long it may take for your team to deliver such functionality...but I'd like to think it can't possibly take another 9 months.

    Our internal Wiki has about 20+ new questions on it...and I may post them as seperate posts on this forum....but I'll keep them around as I'll use them as the main criteria for any synchronization tool we'll evaluate in the future.

    Two last questions:

    1) Will you please release your test tool that you use to diff out two TFS systems? It seems like having such a tool will provide us with a reliable way of testing the integry of any schronization tool.

    2) Can you please share the specific names of who's actually been successful using this new tool, I know you mentioned "Microsoft, Microsoft (MCS) and a few partners" but I'd like specifc email addresses and/or phone numbers of individuals I can email/call and discuss their implimentations?

    Thanks for the dialog and please know that we're really looking forward to some honest to god reliable fully functional migration/synchronization tool.
    Tuesday, December 01, 2009 11:45 PM
  • Allen,

    Thank you for continuing to engage.  Please feel free to post the questions from your internal wiki in related batches to the forum.

    The dev that pulled the code down from CodePlex and evaluated it came to the right decision for your environment, I'm sure.  I think we can count this decision that you've come to in not trying to pick up the alpha drop of the tools as a success in properly messaging and providing guidance.  Your engagment helped us clarify and focus that message, so thanks for pushing to understand the limits and intended audience.

    As mentioned, we use the tools we released to maintain a continuous sync for internal TFS instances that serve thousands of users.  The tools are robust and reliable in our hands.  They are not easy to use yet and they are not really complete - issues well covered in this discussion already.

    The good news about the closed list of features you offered in what you hope to see released by Microsoft is that all are currently in scope.  The bad news is that I can't really offer an assurance of how quickly we'll get any one of these features in.  TFS 2010 is the answer for many people who had a server consolidation problem in the past and other significant migration and synchronization tooling needs, like our ClearCase and ClearQuest tools, are currently higher priority for the majority of the team than working on features with a specific TFS to TFS sync focus in mind.  The features you mention will all likely be byproducts of our ongoing investments in this area, but there are still a number of things ahead of a pure focus on the TFS to TFS problem that could push the timeline for a highly polished TFS to TFS solution out.

    Specifics:
    1) The tools we use to diff out two servers are released: $/MigrationSyncToolkit/IntegrationPlatform/Test/Tools.

    2) No, I'm not really in a position to release information like this.  There were a handful of early adopters - a few moving data between different versions of TFS, a few projecting data to a TFS server in the DMZ and a few building bridges to other systems on the platform to help validate the public APIs.  The alpha bits are now released, so perhaps someone in this forum has a story to share.  

    Bill
    Wednesday, December 02, 2009 6:43 AM
  • Also, my answer to question 11 about baseless merge handling was wrong.  We should be able to handle that now:

    http://blogs.msdn.com/willy-peter_schaub/archive/2009/11/30/tfs-integration-platform-baseless-merge-question-answers-8.aspx

    Bill

    Wednesday, December 02, 2009 12:51 PM
  • It’s official. Much like its predecessor from 2006, the TFS to TFS migration tool, the 2010 TFS Integration Platform is DOA(Dead On Arrival).

    Development of the TFS Integration Platform started in January 2009. It’s now April 2010. It’s been a full 15 months of dedicated resources from MS working on this platform and still there IS NOT an updated TFS Integration Platform release that officially supports the RTM version of the TFS 2010 software.

    Think about that for a moment.

    15 months of ongoing development and even MICROSOFT can’t figure out how to build a solid, reliable, supported platform and toolset that supports integration from 3rd party platforms onto TFS, migrations from 1 TFS server to a second TFS server, and reliable two-way synchronizations between content to and from external platforms (like SharePoint) to TFS.

    I’ve been patiently watching and researching the TFS Integration Platform since October 2009 and the development process has been painfully slow, hasn’t delivered critical features and functionality, and from my DEV team’s testing the TFS TIP doesn’t work without serious hand holding and troubleshooting.

    TFS 2010 and VS 2010 are packed full of nifty and cool features, however the supporting ecosystem for integrating with 3rd party tools and platforms just DOES NOT exist with stable and supported tools from Microsoft.
     
    The release of VS/TFS 2010 may be compelling, however adopt 2010 with your eyes open. You will be in vendor lock-in and there aren’t tools that can move or migrate off the MS platform without serious data loss.

    My advice to the community is the same as it was from 6 months ago (October 2009), wait until Microsoft releases the 3rd version of this platform/toolset before you give it a second glance.

     Maybe I’m wrong; maybe I’m just too cynical; but has even 1 external customers to MS been successful with this tool? And by “successful” I mean just downloading the tool and running it on their own. Google sure doesn’t report any successes and there are plenty of horror stories instead.

    I don’t want to hear about customers who are “successful” only to learn they had to spend hundreds of hours on the phone with PSS in India hacking together QFEs(even if MS provided free support that’s a laughable definition of "success").

    Tuesday, April 20, 2010 1:31 PM
  • Allen,

    The bits on CodePlex should work fine against TFS 2010 RTM.

    I am sorry that you had such a bad experience with the original migration toolkit.  We can’t change that.

    Your assessment of progress and your “critical features and functionality” are just one perspective of many.  Our priorities are aligned to a consensus view that includes demands from customers both large and small that span every single other ALM tool on the market.  You assume in critiquing progress that you see everything and that progress should be measured against your definition of what constitutes success.  It is natural that you would be frustrated by what you see as a lack of progress against your goals when we are focused on something completely different - helping customers with IBM Rational ClearCase and ClearQuest tools. 

    We’re perfectly happy to let our investment in the TFS migration and integration tools area speak for itself over time.

    Bill

    Wednesday, April 21, 2010 8:47 PM
  • I can't seem to find in the TFS TIP includes support for syncronization of the contents of version control labels across TFS servers.

    Has this support been added?

    If not when will it be added?

    Tuesday, October 05, 2010 10:13 PM
  • Where can I get confirmation about label support being included in the TIP? If I do not get confirmation here, is there a email dl where i should ask?
    Saturday, October 09, 2010 1:23 PM
  • Where can I get confirmation about label support being included in the TIP? If I do not get confirmation here, is there a email dl where i should ask?
    Is label support available?
    Friday, December 02, 2011 9:37 PM
  • As per the description on http://visualstudiogallery.msdn.microsoft.com/f854dd59-8eeb-4673-8d9a-ae012989bfa2 labels are not migrated by the current version of the TFS Integration Tools.

    The feature is on the backlog, but we have no information on whether it will be addressed and when it will be available.

    Friday, December 02, 2011 10:32 PM