locked
TF14087: Cannot undelete...because not all of the deletion is being undeleted.

    Question

  • Hi folks,
    I am seeing the following error when attempting a merge:

    TF14087: Cannot undelete '$/Ammado/trunk/Source/Ammado.Web.UI/Controls/LoginPanelControl.ascx.cs' because not all of the deletion is being undeleted.

    I'd like to get to the bottom of it.

    Basically, our setup is that all developers work on a branch, and when they have changes to commit to the trunk, they

    - first merge TO their branch from the trunk,
    - resolve, test and checkin,
    - merge FROM their branch TO the trunk
    - run the automated build and check that the trunk still builds

    I attempt a merge from the trunk to my branch, and Source Control Explorer says that there are no changes to merge

    I then attempt to merge from my branch to the trunk and I see the error above.

    $/Ammado/trunk/Source/Ammado.Web.UI/Controls
    $/Ammado/branches/pmcevoy/Source/Ammado.Web.UI/Controls

    are both empty (I have switched on the "show deleted items in source control explorer" checkbox in my options)., and no "deleted" files are displayed either.

    If I attempt to merge ONLY the "Controls" folder from my branch to the trunk, it says that there are no changes to merge, likewise if I attempt to merge from trunk to branch for thar dir it says  no changes to merge.

    This LoginPanelControl was moved to a different subfolder, and that change WAS merged to the trunk, so I am confused as to why it is starting to look for this file again

    Any help would be greatly appreciated

    Pete


    Monday, July 31, 2006 3:52 PM

Answers

  • Here’s what happened:

    Changeset 213: when you try to merge a rename, TFS throws a conflict.  To make the name change be reflected in the target (trunk in this case) you need to resolve it as AcceptMerge or AcceptTheirs.  The changetype will then be recorded as “merge, rename.”  Looks like you resolved it as AcceptYours, which essentially discards the rename.

    Changeset 220: if you look closely, I’ll bet the files that Merge modified were actually Controls\* rather than en\Controls\*.

    Changeset 222: your guess is probably correct.  If you tried to merge the whole tree, you’d get 1 merge + 1 error, along these lines:

    merge, edit: $/peter/tgt/en/controls/a;C422~C424 -> $/peter/src/controls/a;C423
    TF14119: Cannot merge a delete of $/peter/tgt/controls to $/peter/src/controls because one of its children has been renamed or moved.

    Wouldn’t be surprised if whoever attempted the merge got this error and worked around it by merging the delete and the edit in separate changesets (222 & 223).  Nothing wrong with that, BTW -- it's the best way to complete merges that would otherwise require pending two changes on one slot, and I've advised it before. 

    What you probably didn't notice is that trunk\Controls wasn't empty when you deleted it.  When you make further edits to mybranch\en\Controls\*, Merge needs to undelete those children before it can pend the equivalent edits.  However, in TFS you can only undelete items via the same "deletion root" that they were deleted.  Merge does a check to verify that all undeletes are valid (i.e. their roots are also in the set of items to be merged) -- in your case that check failed. 


    If I'd known all this, the simplest workaround would be to checkin an undelete of mybranch\Controls before merging.  Another workaround would be to re-merge the rename:
    tf undel trunk\controls
    tf checkin /i
    tf merge mybranch trunk /r /force /version:202~202
    tf resolve /auto:acceptmerge
    tf checkin /i

    But as we've all seen, it's hard to debug this sort of deep history on a forum.  Thanks for taking the initiative to dig into the history!  (would've taken years of back & forth chatting)  Hope the explanation makes sense.

    Tuesday, August 22, 2006 6:21 PM
    Moderator
  • Bingo!

    Got it sorted.  OK, FWIW, your last comment, Rich helped me try to figure it out...  I'm not sure exactly, what it was or why... but let me explain the lead up to the point where I started to have problems (for others who may benefit). 

    I gained all the following information from looking at the detail (View History followed by Rightclick "Details") of each of the changesets that have occured on my branch and the trunk for the particular project (Ammado.Web.UI).

    Please excuse me if this is really long winded.... it may help others to understand where I went wrong and help themselves..

    Changeset 131: After converting my project from a website to a web application, I had the following structure:

    Ammado.Web.UI
      \Controls
          LoginPanelControl.ascx
          LoginPanelControl.ascx.cs  (and .cs files)

    Changeset 133: Made some edits to LoginPanelControl.ascx (and .cs and .designer)

    Changeset 157: Merged to trunk.

    Changeset 159: Made some edits to LoginPanelControl.ascx (and .cs)

    Changeset 165: Merged to trunk.

    Changeset 197: Made some edits to LoginPanelControl.ascx

    Changeset 198: Merged to trunk.

    Changeset 202: Later, I wanted to restruture the app to cater for localisation, so I _added_ a dir called "en", and below that I added a dir called "Controls".  My dir structure looked like:

    Ammado.Web.UI
      \Controls
        LoginPanelControl.ascx
      \en
        \Controls


    Changeset 208: Merged to trunk.

    Changeset 213: I then _moved_ LoginPanelControl.ascx to the en\Controls subdir, so that the structure looked like:

    Ammado.Web.UI
      \Controls
      \en
        \Controls
          LoginPanelControl.ascx

    However, what confuses me about this changeset, is that the move is registered as a _merge_.  Maybe _this_ is the problem?  But allow me to continue:

    Changeset 215: Merged to trunk
    Changeset 218: Merged to trunk

    Changeset 219:  I made a modification to LoginPanelControl.ascx (corrected a typo in the file)

    Changeset 220: Merged to trunk

    Changeset 221: I deleted the (now) empty Controls subdir from the project root, so my structure looks like:

    Ammado.Web.UI
      \en
        \Controls
          LoginPanelControl.ascx

    In this changeset I also made an edit to LoginPanelControl.ascx.

    Changeset 222: Merged to trunk (although in this merge, only the delete of the controls dir seems to have registered - perhaps at this point I only selected the Controls dir to merge?

    Changeset 223: Merged to trunk, this time included were the changes that had been made to LoginPanelControl.ascx

    It is at this point that I started to see the "Undelete" problem.

    Now, to fix the problem, at your prompting, I made a copy of LoginPanelControl.ascx (and .cs) files and removed them from the "en\Controls" dir on my branch. 

    Changeset 243: Deleted LoginPanelControl.ascs, (and .cs and .designer)

    Changeset 244:  Merge to mainline (YES!)

    Changeset 245: Readded LoginPanelControl.ascs (and .cs, .designer) on my branch

    Changeset 246: Merged to mainline (YES^2!) and tested build - all is well!

    So thanks for your patience, this has worked out in the end (although I've lost the history of LoginPanelControl, at least it is only this ONE file).

    Perhaps you could comment on where I may have gone wrong so that I (and others) could perhaps avoid this problem?

    Sincerely
    Pete


    Tuesday, August 22, 2006 10:02 AM

All replies

  • I've tried creating a new workspace and doing the merge within that, and still no joy. 

    This feels like some kind of server corruption: it's as if the merge is trying to play changes to a file that no longer exists because it's containing folder has been removed.

    I'd really appreciate some help, as I don't fancy going back to a back up of the DB

    Pete
    Wednesday, August 2, 2006 9:00 AM
  • I'm sorry to hear that you are having difficulty getting this command to work as you expected.

    The following thread describes a similar situation and has some advice from Richard about situations where this can happen.

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=368938&SiteID=1

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=406233&SiteID=1

    In the case of the second thread it was determined that the cause was a bug in the B3R release of TFS that was fixed in RTM.  Can you confirm whether or not you are using RTM?

    Thanks.

    Robert

     

    Wednesday, August 2, 2006 11:29 AM
  • Thanks Robert,

    I had seen those two threads before I posted, but the info in them did not seem to help.  Regarding the first thread, I am not sure how to go about a baseless merge or what the implications of it may be - is this advisable?

    With regard to the second thread and your question, yes, we are running the RTM.  So no joy there.

    In both threads, they seem to be able to narrow down on spcific changesets that are causing the problem - is this something I should be trying to find out?

    Sincerely Pete
    Wednesday, August 2, 2006 11:39 AM
  • Hi folks,
    Just refreshing this thread, as it's still an outstanding problem for me...  I can provide more information, but at this point, I'm really at a loss as how to progress....

    Pete
    Tuesday, August 8, 2006 8:46 AM
  • I've never seen this message be returned erroneously.  The canonical example is self-explanatory:
    mkdir src\foo
    touch src\foo\bar.txt
    add src /r
    checkin
    merge src tgt /r
    checkin
    del src\foo
    checkin
    merge src tgt /r
    checkin
    undel src\foo
    checkin
    merge src\foo\bar.txt tgt\foo\bar.txt
    <TF14087>

    Of course, finding how/why this condition arises during a real-world merge can be tricky.  Can you post:
    - the exact command you're running
    - the output of tf history $/Ammado/trunk/Wherever-you-moved-it-to/LoginPanelControl.ascx.cs /i
    Friday, August 11, 2006 8:53 PM
    Moderator
  • Hi Richard,
    I am unsure of the exact "tf" command I am running as I am selecting the "Merge" option from the source control explorer in VS2005.  I am trying to merge from my branch to the trunk.  Within the merge dialog wizard, I am using the default options:  "All Changes up to a specific version", Version type: Latest Version, and then I click "Finish" and I get the error as detailed above.

    With regard to your second request, here is the output of the command:


    C:\Ammado\Trunk\Source\Ammado.Web.UI\en\Controls>tf history $/Ammado/Trunk/Source/Ammado.Web.UI/en/Controls/LoginPanelControl.ascx.cs /i
    Changeset Change               User          Date       Comment
    --------- -------------------- ------------- ---------- -----------------------------------------------------------------------------------------------------------------------------------------------
    215       merge                pmcevoy       31/07/2006 213 -   211 - Added description text to each page  210 - More content for website
    208       merge, rename, edit  pmcevoy       31/07/2006 Added skeleton website and initial pass at pages and controls
    165       merge, edit          pmcevoy       24/07/2006 164 - Added working tests for AuthenticationService - Added failing tests for AccountManager, and Stub interface to AccountM...  163 - Added a
    157       branch               pmcevoy       21/07/2006 Restoring directory that had somehow got deleted by my bad merge

    C:\Ammado\Trunk\Source\Ammado.Web.UI\en\Controls>



    Please let me know if there is any more information I can get you - I'd really like to get this resolved

    Pete

    Monday, August 14, 2006 4:58 PM
  • 'Restoring directory that had somehow got deleted by my bad merge'

    This is a clue.  I'll bet there's a deleted item with the same name lurking in the database, and Merge is trying to pend changes on it. 

    Unfortunately I can't tell you whether it's a bug or by-design without running several more History and Dir /deleted commands at minimum.  It may be easier to examine the database directly.  If you call Customer Support they can guide you through the process of extracting VC data sans file contents and pass it on to the product team.
    Monday, August 14, 2006 10:31 PM
    Moderator
  • Richard,
    Yes, this is the case: several merges ago the contents of the directory were removed after I botched upgrading my web site project to a web application project with the same name: I renamed the original website project to project_BAK, created the new web application project with a directory name the same as the original, and did some moving around of existing files - however after I merged these changes to the mainline, the directory on the mainline was empty (I probably clicked the wrong option on "do you want to keep source or target").  I then did some manual fiddling around to get the contents into the mainline.  However I thought I was OK, as merges after that point seemed to go ok.

    Anyway, the short of it is that I suspect it will be like staring into a bush to figure out how to clean this up correctly, and I'd rather not get envolved in a drawn out support process, (unless of course you think that it would not be)?

    Is there anyway that I can force the mainline to take the changes that are on my branch for this directory  (ie baseless merge or equivalent - I'm not even sure I'm using the right terminology here?).  I do know that no one else on the team has merged to the mainline in this project, so it feels like it could be a "force" type option....

    Sincerely
    Pete
    Tuesday, August 15, 2006 8:40 AM
  • Hi Pete,

    Have you had any luck resolving your issue?  If not please let me know and I can find someone to provide more help.

    Thanks,
    -Matt

    Monday, August 21, 2006 2:46 PM
    Moderator
  • Hi Matt,
    No, I have had no luck.  I do need to get it fixed in the next few weeks as I am lucky at the moment cos no one else on the team has done a merge to the trunk since this mess up (most are on holidays), so it should be easy to fix via a "forced" merge to the mainline.

    I got our support details from my manager this morning, so I can log a support call if you feel that I should take this thread "off-line".

    Sincerely
    Pete
    Monday, August 21, 2006 2:56 PM
  • Please don't take this thread off-line as we having same problem. Thanks!
    Monday, August 21, 2006 10:38 PM
  • If you can figure out which item in the source is trying to merge to
    $/Ammado/trunk/Source/Ammado.Web.UI/Controls/LoginPanelControl.ascx.cs,
    one workaround would be to delete that item and re-add it. That way
    Merge will branch it into the target as a new item instead of trying to
    resurrect the old one.
    Monday, August 21, 2006 11:10 PM
    Moderator
  • Bingo!

    Got it sorted.  OK, FWIW, your last comment, Rich helped me try to figure it out...  I'm not sure exactly, what it was or why... but let me explain the lead up to the point where I started to have problems (for others who may benefit). 

    I gained all the following information from looking at the detail (View History followed by Rightclick "Details") of each of the changesets that have occured on my branch and the trunk for the particular project (Ammado.Web.UI).

    Please excuse me if this is really long winded.... it may help others to understand where I went wrong and help themselves..

    Changeset 131: After converting my project from a website to a web application, I had the following structure:

    Ammado.Web.UI
      \Controls
          LoginPanelControl.ascx
          LoginPanelControl.ascx.cs  (and .cs files)

    Changeset 133: Made some edits to LoginPanelControl.ascx (and .cs and .designer)

    Changeset 157: Merged to trunk.

    Changeset 159: Made some edits to LoginPanelControl.ascx (and .cs)

    Changeset 165: Merged to trunk.

    Changeset 197: Made some edits to LoginPanelControl.ascx

    Changeset 198: Merged to trunk.

    Changeset 202: Later, I wanted to restruture the app to cater for localisation, so I _added_ a dir called "en", and below that I added a dir called "Controls".  My dir structure looked like:

    Ammado.Web.UI
      \Controls
        LoginPanelControl.ascx
      \en
        \Controls


    Changeset 208: Merged to trunk.

    Changeset 213: I then _moved_ LoginPanelControl.ascx to the en\Controls subdir, so that the structure looked like:

    Ammado.Web.UI
      \Controls
      \en
        \Controls
          LoginPanelControl.ascx

    However, what confuses me about this changeset, is that the move is registered as a _merge_.  Maybe _this_ is the problem?  But allow me to continue:

    Changeset 215: Merged to trunk
    Changeset 218: Merged to trunk

    Changeset 219:  I made a modification to LoginPanelControl.ascx (corrected a typo in the file)

    Changeset 220: Merged to trunk

    Changeset 221: I deleted the (now) empty Controls subdir from the project root, so my structure looks like:

    Ammado.Web.UI
      \en
        \Controls
          LoginPanelControl.ascx

    In this changeset I also made an edit to LoginPanelControl.ascx.

    Changeset 222: Merged to trunk (although in this merge, only the delete of the controls dir seems to have registered - perhaps at this point I only selected the Controls dir to merge?

    Changeset 223: Merged to trunk, this time included were the changes that had been made to LoginPanelControl.ascx

    It is at this point that I started to see the "Undelete" problem.

    Now, to fix the problem, at your prompting, I made a copy of LoginPanelControl.ascx (and .cs) files and removed them from the "en\Controls" dir on my branch. 

    Changeset 243: Deleted LoginPanelControl.ascs, (and .cs and .designer)

    Changeset 244:  Merge to mainline (YES!)

    Changeset 245: Readded LoginPanelControl.ascs (and .cs, .designer) on my branch

    Changeset 246: Merged to mainline (YES^2!) and tested build - all is well!

    So thanks for your patience, this has worked out in the end (although I've lost the history of LoginPanelControl, at least it is only this ONE file).

    Perhaps you could comment on where I may have gone wrong so that I (and others) could perhaps avoid this problem?

    Sincerely
    Pete


    Tuesday, August 22, 2006 10:02 AM
  • Here’s what happened:

    Changeset 213: when you try to merge a rename, TFS throws a conflict.  To make the name change be reflected in the target (trunk in this case) you need to resolve it as AcceptMerge or AcceptTheirs.  The changetype will then be recorded as “merge, rename.”  Looks like you resolved it as AcceptYours, which essentially discards the rename.

    Changeset 220: if you look closely, I’ll bet the files that Merge modified were actually Controls\* rather than en\Controls\*.

    Changeset 222: your guess is probably correct.  If you tried to merge the whole tree, you’d get 1 merge + 1 error, along these lines:

    merge, edit: $/peter/tgt/en/controls/a;C422~C424 -> $/peter/src/controls/a;C423
    TF14119: Cannot merge a delete of $/peter/tgt/controls to $/peter/src/controls because one of its children has been renamed or moved.

    Wouldn’t be surprised if whoever attempted the merge got this error and worked around it by merging the delete and the edit in separate changesets (222 & 223).  Nothing wrong with that, BTW -- it's the best way to complete merges that would otherwise require pending two changes on one slot, and I've advised it before. 

    What you probably didn't notice is that trunk\Controls wasn't empty when you deleted it.  When you make further edits to mybranch\en\Controls\*, Merge needs to undelete those children before it can pend the equivalent edits.  However, in TFS you can only undelete items via the same "deletion root" that they were deleted.  Merge does a check to verify that all undeletes are valid (i.e. their roots are also in the set of items to be merged) -- in your case that check failed. 


    If I'd known all this, the simplest workaround would be to checkin an undelete of mybranch\Controls before merging.  Another workaround would be to re-merge the rename:
    tf undel trunk\controls
    tf checkin /i
    tf merge mybranch trunk /r /force /version:202~202
    tf resolve /auto:acceptmerge
    tf checkin /i

    But as we've all seen, it's hard to debug this sort of deep history on a forum.  Thanks for taking the initiative to dig into the history!  (would've taken years of back & forth chatting)  Hope the explanation makes sense.

    Tuesday, August 22, 2006 6:21 PM
    Moderator
  • Thanks for your help, Rich.  It does make sense.  At least now I have a good idea how to investigate these issues using changeset details, and be self sufficient!


    Pete
    Tuesday, August 22, 2006 7:25 PM
  • I am facing the same issue as mentioned here:

     

    ---------------------------
    Microsoft Visual Studio
    ---------------------------
    Source Control Merge Wizard

    Merge encountered 0 error(s) and 2227 warning(s).

    First error/warning encountered:

     

    TF14087: Cannot undelete '$/Project/02 Mainline/OldFolder/Code/Folder' because not all of the deletion is being undeleted.

     

    See output tool window for information on any other errors.
    ---------------------------
    OK   Help  
    ---------------------------

    I am trying to merge from $/Project/01 Development to $/Project/02 Mainline. The OldFolder has been deleted. I can do an undelete of OldFolder and the Code subfolder but all the other files and folders cannot be undeleted. I am talking of about 2227 files hence the 2227 warnings which is confirmed in the output window.

     

    Any ideas on how to crack this nut?

    Thursday, May 3, 2007 8:34 AM
  • For what it's worth...there have been cases where branching the specific item (followed by a check-in) has solved this issue. 
    Friday, July 31, 2009 5:15 PM