# 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 • 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
• 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 • 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 • 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
• 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:

\Controls

Changeset 157: Merged to trunk.

Changeset 165: Merged to trunk.

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:

\Controls
\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:

\Controls
\en
\Controls

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:

\en
\Controls

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 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
• 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