locked
Confusing Conflict RRS feed

  • Question

  • I am trying to migrate a project from my TFS 2008 server to my new TFS 2010 server.  I have migrated several projects successfully to a test TFS 2010 sever and one (different one) successfully to this new server.

    But now I am getting a conflict that has me stuck.

    Here is my scenario:

    The project I am trying to Migrate is called SHR-Framework.  I setup the migration just as I would any other project.  It had found 11 "change groups" and then I got this conflict:

    The following path is not mapped in the target system: $/VSS Legacy/Dev/Delphi/SecurityService

    VSS Legacy is a project that I have not migrated yet.  So to fix this conflict, I created the project (on my target TFS 2010 server) and then I added a mapping to the $/VSS Legacy root on my system I am using for migrating.  I then select the option that says "Change the configuration and retry the operation(Requires user to manually add the path or its parent path to the mapping). "

    I selected "start" to get the migration going again and it gave me the same error message but for a different path in $/VSS Legacy project.  I selected the "change configuration " option and clicked resolve.  That happened several times.  Eventually the migration tool said it completed so I thought that those files had been figured out.  But the users of the project reported that most of the files were missing from source control.

    I went and looked at the help for the conflict and it says:

    This conflict occurred because the path to be migrated is not mapped on the source system.

    So, now I am getting a bit frustrated because the conflict says "target" and the help says "source".

    I went and added a mapping on the source system too (TFS 2008).  But when I ran the tool it just runs for a short bit and then says it was successful.

    I have had an issue like this before and I knew that there was no fix for it (I reported it before but it could not be reproed).  So I deleted the project from my TFS 2010 server (and sharepoint) and made it again.

    I then created a new migration and started it, thinking that Now, Finally I had sorted everything out and it would run fine.  But not so.  I got the error again!!!!

    So this time I selected: "Resolve this conflict by changing to 'Add" for 'Branch', by skipping for 'Merge' and by changing to 'Add' for 'Remove'. "

    But now it is just stuck at 11 "change groups" found. 

    Any ideas what I can do to get past this?  I am starting to look bad here.  I was fairly sure that this tool was ready for prime time so I pushed the migration to TFS 2010.  Now it is looking like the tool cannot handle some of our TFS Projects.

    Monday, December 20, 2010 9:41 PM

Answers

  • Hi Vaccanoll,

    Sounds like you've hit on one of the most common reasons for folks to use the migration tool rather than an upgrade - switching process templates.  I hope that in the future, TFS will make this easier than requiring you to copy your data into a new team project.

    As for your conflict, I see from your config that you're simply mirroring $/SHR-Framework between the 2 servers.  The conflict you're getting generally comes about when some changes on the source system (the "left" system) came about through a branch operation, but the parent of that branch operation does not exist on the target system (the "right" system).  The migration tool is trying to replay the history of the left system on the right system to re-create the data.  Your conflict would indicate that at some point the code under "$/VSS Legacy/Dev/Delphi/SecurityService" was branched under $/SHR-Framework.  Can you confirm that's the case?

    The conflict gives you 2 resolution options, both of which could be improved (I'll be filing a bug for that).  The first option says "I don't care about the branch relationships on the target system so translate the operations on the left into something that makes sense without the branch parent existing on the right."  We do that by applying 3 transforms that the text attempts to explain here:

    1. Branch operations on the left are converted to Add operations on the right.
    2. Merge changes on the left are dropped, migrating the remaining change types to the right.  Generally, a merge operation is always accompanied by an edit, rename, delete, etc.  What this says is it'll just migrate over the edit/rename/delete operation, but the fact that those happened during a merge from "$/VSS Legacy/Dev/Delphi/SecurityService" will be lost.
    3. Rename operations will be converted to Adds.  Under the covers, TFS treats a rename operation very similarly to a branch operation.  If you renamed a file from "$/VSS Legacy/Dev/Delphi/SecurityService" into $/SHR-Framework, TFS would track that for you, but since "$/VSS Legacy/Dev/Delphi/SecurityService" doesn't exist on the target system, we'll lose track of that during the migration.

    The second resolution option says "I've modified the system in some way as to eliminate the problem here and let you retry it."  The assumption is that you've gone through a bunch of manual work to add the branch parent to your migration session with a snapshot start point specified that happens to map to the current synchronization point on the left system and you've manually checked in the code as of that snapshot start point on the right side with a special checkin comment that tells the migration tool to not try to migrate that back to the left system if you're doing a 2-way sync.  Yes, this is more complicated that is fair for us to expect you to get through without mistakes.  Apparently, we just didn't get around to automating the process, didn't think to block it entirely in this release, and haven't shipped a new release with the feature completed.

    So, for your situation, I think you probably want to start clean with a new migration.  You should be able to delete or destroy the already migrated source in the right system to clean that up, or you can migrate into a different location.  When you set up your migration, either include the "$/VSS Legacy" branch in the initial migration, or choose the first conflict resolution that says "I don't care about the branch relationships."

    I hope the long explanation helps.  I want to thank you for sourcing several bugs that I'll file right now and hopefully we'll clean this up significantly after the holidays and get an improved experience around this in your hands before long.

    Thanks,
    -Doug


    Group Program Manager, Team Foundation Server
    • Marked as answer by Vaccanoll Monday, May 9, 2011 4:11 PM
    Wednesday, December 22, 2010 4:46 PM

All replies

  • Hi Vaccanoll,

    I wouldn't be surprised if the help file mixed up "source" and "target" here.  Unfortunately, it's easy to mix up those terms and have reviewers not notice it, however I understand that it's extermely frustrating to the end user.  I'll make sure we get that one fixed.

    Would you mind pasting in your config file here so we can look at it?  I'll get one of the devs to make sure everything looks kosher and see if we can't figure out what's going on.

    Finally, you know that for most scenarios the right way to get from TFS 2008 to TFS 2010 is to do an in-place upgrade of your server, right?  Using the migration tool is lossy.  That said, there are legitimate reasons you'd want to migrate rather than upgrade - I just want to make sure you've thought through them.

    Thanks,
    -Doug


    Group Program Manager, Team Foundation Server
    Tuesday, December 21, 2010 5:35 PM
  • Doug,

    >I'll make sure we get that one fixed

    Glad to hear it (I look forward to finding out which one it really should be)

    > the right way to get from TFS 2008 to TFS 2010 is to do an in-place upgrade of your server ... I just want to make sure you've thought through them.

    I thought through it good amount.  We were using Scrum For Team System (SFTS) v2 as our TFS 2008 Template.  That template does not work in TFS 2010.  So we are using the migration tool to migrate from TFS 2008 SFTS v2 to the TFS 2010 Visual Studio Scrum 1.0 template.

    >Would you mind pasting in your config

    I saved off my config here: https://gist.github.com/raw/750495/2f4635ca7ce539ff0ac3e4706aadf827d02f4830/Configuration.xml

    I got it by exporting and then opening the _Configuration.xml file.  I tried to paste it into this post, but I kept getting a HUGE error box (with a lot of HTML) every time I tried.

     


     

    Tuesday, December 21, 2010 8:08 PM
  • Hi Vaccanoll,

    Sounds like you've hit on one of the most common reasons for folks to use the migration tool rather than an upgrade - switching process templates.  I hope that in the future, TFS will make this easier than requiring you to copy your data into a new team project.

    As for your conflict, I see from your config that you're simply mirroring $/SHR-Framework between the 2 servers.  The conflict you're getting generally comes about when some changes on the source system (the "left" system) came about through a branch operation, but the parent of that branch operation does not exist on the target system (the "right" system).  The migration tool is trying to replay the history of the left system on the right system to re-create the data.  Your conflict would indicate that at some point the code under "$/VSS Legacy/Dev/Delphi/SecurityService" was branched under $/SHR-Framework.  Can you confirm that's the case?

    The conflict gives you 2 resolution options, both of which could be improved (I'll be filing a bug for that).  The first option says "I don't care about the branch relationships on the target system so translate the operations on the left into something that makes sense without the branch parent existing on the right."  We do that by applying 3 transforms that the text attempts to explain here:

    1. Branch operations on the left are converted to Add operations on the right.
    2. Merge changes on the left are dropped, migrating the remaining change types to the right.  Generally, a merge operation is always accompanied by an edit, rename, delete, etc.  What this says is it'll just migrate over the edit/rename/delete operation, but the fact that those happened during a merge from "$/VSS Legacy/Dev/Delphi/SecurityService" will be lost.
    3. Rename operations will be converted to Adds.  Under the covers, TFS treats a rename operation very similarly to a branch operation.  If you renamed a file from "$/VSS Legacy/Dev/Delphi/SecurityService" into $/SHR-Framework, TFS would track that for you, but since "$/VSS Legacy/Dev/Delphi/SecurityService" doesn't exist on the target system, we'll lose track of that during the migration.

    The second resolution option says "I've modified the system in some way as to eliminate the problem here and let you retry it."  The assumption is that you've gone through a bunch of manual work to add the branch parent to your migration session with a snapshot start point specified that happens to map to the current synchronization point on the left system and you've manually checked in the code as of that snapshot start point on the right side with a special checkin comment that tells the migration tool to not try to migrate that back to the left system if you're doing a 2-way sync.  Yes, this is more complicated that is fair for us to expect you to get through without mistakes.  Apparently, we just didn't get around to automating the process, didn't think to block it entirely in this release, and haven't shipped a new release with the feature completed.

    So, for your situation, I think you probably want to start clean with a new migration.  You should be able to delete or destroy the already migrated source in the right system to clean that up, or you can migrate into a different location.  When you set up your migration, either include the "$/VSS Legacy" branch in the initial migration, or choose the first conflict resolution that says "I don't care about the branch relationships."

    I hope the long explanation helps.  I want to thank you for sourcing several bugs that I'll file right now and hopefully we'll clean this up significantly after the holidays and get an improved experience around this in your hands before long.

    Thanks,
    -Doug


    Group Program Manager, Team Foundation Server
    • Marked as answer by Vaccanoll Monday, May 9, 2011 4:11 PM
    Wednesday, December 22, 2010 4:46 PM
  • Doug,

    That is a high quality answer!  Thank you so much for taking the time to explain that to me.

    However, I think I have also confused the system (by selecting option 2 many many times).  Now when I select the "first option" and it does not continue on (even after deleting the project and making a new migration"project".

    I think I have confused the system and to get it to work, I would have to rename my project to a different name (just a guess).  But that will cause other problems (with the way we track projects).

    Happily all my work items can migrate.  It is just my source that will not migrate.  The project I am migrating is able to just make a clean break with the source at this time.  I will just check in the "tip" and keep our old TFS server around for history.

    However, I have a lot more projects to migrate (over 20).  So I look forward to any new versions you guys put out on this. 

    But in the future I will likely just select option one (the Branch/Merge history between TFS Projects is not so important to us)

    Wednesday, December 22, 2010 6:55 PM
  • So, for your situation, I think you probably want to start clean with a new migration.  You should be able to delete or destroy the already migrated source in the right system to clean that up, or you can migrate into a different location.  When you set up your migration, either include the "$/VSS Legacy" branch in the initial migration, or choose the first conflict resolution that says "I don't care about the branch relationships."

    This very old post has been very helpful to me. I am wondering though about the option to create a rule.

    I am having the same issue, I chose the first option to not care about the relationship. This migration was for a us to test out the process and I have to redo the migration into the real destination. One of the migrations I did stopped many many times because of this situation. I don't want to babysit the migration. Is there a way to tell TFS Integration to use that first option whenever it comes to the situation?

    Thank you for you helpful post nearly 2 years ago. I hope this question makes it to you and someone can help out.

    Friday, March 2, 2012 5:32 PM