0

I've been given the dubious hack of a task to stop tracking all "TFS stuff" from about a month back to the time it first started. Why? Because it's currently a behemoth. Over half a million files and close to six digits of changesets across loads of inter/cross-connected branches for a "legacy" code repository where no one cares about the "old stuff"'s history or access to old files, but they need what's currently in the repo to stay there.

The problem is, at its current state it is making interacting with TFS a huge pain. The few devs who still touch this code base often have IDE crashes when trying to do simple things like, access the source control explorer, checkin, etc... really basic things have become sketchy from TFS bloat. If I want to merge a single changeset from one active branch to another, I get lag with the lists loading for 5-10 minutes instead of a few seconds.

While researching, I ran across this old question. It seems like it may be what I need, but I'd hate to find out the hard way that I used the commands incorrectly and have to re-load the snapshot for our TFS server, as this repo is worked on in multiple timezones.

How do I reset/purge history, shelvesets, work items, and anything else before say, C20,0000, meaning, I don't care about anything before C20,000, but I want all the files that exist at the time of C20,000, even if one of those files was part of say, C12, but is still in the repo and unchanged.

If the linked-to answer provides the answer I need, but not the clarity, I'm fine closing this as a dupe so long as the other answer gets updated with clarification.

I'd like to do something along the lines of this pseudo-code:

tfs nuke $collection/$ProjectName beforeChangeset:C20000 /keepCurrentFiles

I'm guessing that will require multiple commands for things like files and shelvesets, but that's the gist of what I'm trying to accomplish.

Community
  • 1
  • 1
kayleeFrye_onDeck
  • 6,648
  • 5
  • 69
  • 80
  • 1
    It seems unlikely that the number of changesets is the cause of your stability issues. How big is the collection database in SQL server? Have you run the best practice analyser against TFS? Is the hardware hosting the TFS server up to the task? I've worked with TFS repos significantly bigger than this and not seen the same problems – James Reed Jul 07 '16 at 09:05
  • @JamesReed Thank you for the input! I got some of those details from the old DBA: "_Best practice analyzer used?_" -- **Not in a long time, and when we did run it, our custom build model made many of those recommendations prohibitive.** "_Collections size?_" -- **~200GB on 2TB of SSD allocated. a little over 1TB is being used.** "_Hardware up to task?_" -- **When monitoring the system while doing intensive tasks, the only resource spike was disk usage. It _is_ a VM though.** I tried talking them into switching to physical, but they won't budge :( – kayleeFrye_onDeck Jul 07 '16 at 18:21
  • 3
    Are your developers using local workspaces and mapping the entire collection? That would definitely explain why Visual Studio (or Team Explorer actually) is acting up. [see this article](https://www.visualstudio.com/en-us/docs/tfvc/decide-between-using-local-server-workspace). I cannot imagine that TFS is unable to handle the amount of data since Microsoft uses dogfeeding server to push TFS to its limits internally. See [this old post](https://blogs.msdn.microsoft.com/bharry/2011/06/02/team-foundation-server-dogfooding-update-may-2011/). Do you have single server of an AT/DT setup? – Sander Aernouts Jul 08 '16 at 06:38
  • @SanderAernouts good shout on the local workspaces. – James Reed Jul 08 '16 at 17:19
  • 1
    @kayleeFrye_onDeck 200GB doesn't sound massive, that database will also be hosting work items, attachments, test results, build history and a bunch of other stuff. I wouldn't worry about that fact that the TFS server is a VM, that's fairly normal. It is worth asking your DBA to look at the amount of memory being used inside SQL server as the database itself may be memory constrained. – James Reed Jul 08 '16 at 17:22
  • A lot of those developers have most of each branch they're working on mapped locally, but certainly not the entire collection. I can re-check the active devs' workspaces though. It seems so strange, as each branch really hasn't grown much in the last calendar year, but the sluggishness has gotten pretty bad. I'll advise them to use only one workspace per branch and see if that helps. @JamesReed the DBA said the size allocated for the SQL server database is about 8GB on a VM with 24GB allocated in a WinServ2008 R2 box o.0 I have no idea how good/bad that is for this context... – kayleeFrye_onDeck Jul 08 '16 at 20:19
  • @JamesReed I had our devs update their local workspaces, as well as purged a lot of older stuff that I knew no one would ever care to reference. No one is complaining about performance issues now. For the sake of completeness in case someone does end up wanting to do this, for whatever reason, would tf destroy without deleting the files + re-committing all files as new files do the trick for the original question? If so, what precise syntax would you use? I'd like to accept that as an answer to close this thread. – kayleeFrye_onDeck Jul 11 '16 at 21:27

0 Answers0