Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Any branch or item that is "deleted" remains in history. Any branch or item that is destroyed is removed from the database and is therefore not in history. There is not a /keephistory option on a delete because all deletes keep history. I have not personnally used the /keephistory with the destroy command so I can't give you a recommendation on it. Just reading the documentation for it <a href="http://msdn.microsoft.com/en-us/library/bb386005.aspx" rel="nofollow">here</a> I would guess that the difference between a regular delete and a destroy with /keephistory on is that the destroy can't be reversed. </p> <p>In the situation you describe I would not recommend destrying the branch because that is where your history about who changed what lives. When you merge there is only a single check-in that includes all changes merged and it is associated with however checked in the merge.</p> <p>Before TFS 2010 the history for merges was difficult to follow but possible if you took the time to figure it out. In TFS 2010 it is much easier to see the flow of a change through branches.</p> <p>I could answer better if I knew your reasoning behind wanting to destroy but here are a couple things to think about: If you are destroying to help you reduce disk space 1) branches don't cost much because they only keep the difference not an entire copy 2)if you are destroying to save disk space and you use /keephistory I would guess that it doens't reduce the disk space usage. If you are destroying because OMG the code is trash and nobody should ever have the chance to be subjected to it's horror, then you are probably overthinking things.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload