Does the delete shelveset operation reclaim space used by the changeset in tfs database?
I don't want to know the details, just want to know - will the space be reclaimed, or the database will grow, if i create and delete many big shelvesets?
Shelvesets are essentially uncommitted pending changes with a special flag set that identifies them as a shelveset rather than a normal workspace.
When you delete a shelveset, the pending changes are undone and the content is flagged for removal.
If the shelveset is quite large and you were hoping to free up disk space on your server, you should know that the space won't immediately be released back to SQL, but it will eventually be. At a high-level, the following things have to happen:
TFS has a built-in job (Version Control Administration Job) that runs nighlty and clears up destroyed content.
There is another job (Optimize Databases) which will reorganize/rebuild SQL indexes
SQL will also need to run it's "ghost cleanup" process to release the pages
Unless you shrink the SQL data files, SQL will retain the space as 'free pages' and not return it to the operating system.
The spaced used by the shelveset will be reclaimed when deleted. Shelvesets are like workspaces on the server and when you delete the shelveset the corresponding rows are deleted.
Related
I have the following problem with Team Foundation Server Express 2015.
I ran out of SQL Database Space. So I cleaned up a littlebit and used TFS Destroy to permanently delete some larger files from source control.
I expected that the Size auf the table dbo.tbl_Content would get less after some time. But the opposite happened. 3000 Entries where added to the table and it got larger.
How can I cleanup TBL_Content from old files that have been destroyed already?
The TBL_Content Table has now 8.8 GB.
Executing stored procedures like prc_DeleteUnusedContent and [dbo].prc_DeleteUnusedFiles did not help at all.
Orphan data still leaves after running the tf destroy command, and will be deleted later by a TFS Background job agent. That is the reason why table dbo.tbl_Content size doesn't drops.
Here are some steps you can try to reduce the size of TFS databases:
1). Download and install TFS2015 Power Tool to get the Test Attachment Cleaner to remove large test attachments:
Tcmpt.exe attachmentcleanup /collection: TeamProjectCollectionUrl /teamProject: TeamProject /settingsFile: SettingsFilePath [/outputFile: ReportFilePath] [/mode: Preview/Delete]
2). Remove old workspaces which is no longer used for long time.
3). Delete old unused team projects: https://msdn.microsoft.com/en-us/library/ms181482(v=vs.140).aspx
Mistakenly, I did undo operation on my TFS checkout and I lost all my changes.
Is there a way to get back changes or reverse of undo operation?
I checked, I can not restore with Windows restore option.
Not through any mechanism that TFS provides; when you undo a pending change, the original contents of the file at your workspace version will be placed on disk, overwriting any changes you've made.
You may be able to use some undeletion tool to recover the file contents.
In the future, you may use TFS shelvesets to back up your changes to the server.
Is it possible to archive old data from MS Team System Source Control? We have up to 10,000 changesets in our TFS database, and are unlikely ever to want to go that far back, but the database files are getting ever larger. Is it possible to archive everything before a certain date (say) to reduce the size of the database? if not, taken to its logical conclusion a long lived actively developed project will eventually explode.
You can back up the whole TFS database and then use destroy command to permanently delete the source control tree. But you can do that only for whole source control paths, not specific versions.
In case there are many deleted files you can also use the same command to review the source control tree and permanently destroy these deleted files.
You will not be able to just delete old changesets because TFS stores incremental changes every time you check-in. This also implies that maybe you have large binary files stored in TFS - files larger than certain limit are not stored incrementally (thus saving space) but instead every version is stored complete.
Documentation on the command: http://msdn.microsoft.com/en-us/library/bb386005(v=vs.100).aspx
In TFS, if you want to create a personal branch to try out an idea you
have, you will have to create a branch on the TFS server – even if no
one else needs access to your code. And when you create this branch,
every single file in your project will be duplicated – even if your
branch has very few changes compared to the original one. Now you’re
using twice the amount of disk space both on the server and locally!
Is this true, and one of the downsides of a non-distributed VCS?
Both statements are wrong. (Where did you read this?)
In TFS, if you want to create a personal branch to try out an idea you have, you will have to create a branch on the TFS server
No you don't always need a branch if you're just "trying out an idea". Of course it depends on what you want to do. Saving your work on the server to secure it against drive crashes is what shelvesets are for in TFS (other VCSs may not provide anything similar, which is why you need to create a branch for every idea there). You can even share your code with others without actually checking it in using shelvesets. Even a simple kind of versioning can be done by including the timestamp in the names of the shelvesets, but this is tedious, probably more so than creating a branch ;) Building your code on the server is another thing you can do with shelvesets.
You should read up on when to use shelvesets over changesets on MSDN (there is an article somewhere) to decide whether you need a new branch.
Now you’re using twice the amount of disk space both on the server and locally!
The copying of the code only happens virtually. The SQL Server behind the TFS Server will not use up twice the space, unless every file actually changes on either one of these branches. Until then, both files on the two branches will "point" to the exact same memory on the SQL Server. If you need to work on both branches simultaneously and map them into your workspace, then of course you need twice the amount of space locally. Both is true for any VCS I am aware of, so this is not a TFS-specific issue.
Is it possible to view history and compare with shelvesets? We are investigating the possibility of using shelvesets instead of check-ins. From our initial investigation it seems we cannot view history like we do for check-ins.
We are using Visual Studio 2010/TFS 2010.
From http://msdn.microsoft.com/en-us/library/ms181403(v=vs.90).aspx
Section: The Difference Between Changesets and Shelvesets:
Unlike a changeset, a shelveset is a non-versioned entity. If you or another user unshelve the items of which a shelveset consists, edit several files, and reshelve the shelveset, Team Foundation does not create a new version of the items for future comparison and maintains no record of who revised the items, when, or in what manner. The original shelveset is completely replaced.
So, no, you can't review history. I am unsure on methods of comparing shelvesets. You should also read that entire section (The Difference Between Changesets and Shelvesets) as each item in it is a strong argument to not use shelvesets in the place of changesets.
I also cannot think of any reason why using shelvesets instead of changesets would be desirable, maybe you can list the reasons why you all were exploring this path. Just think about not being able to track changes, that alone should be a deal breaker (of course, shelvesets not even being versioned should just about do it)..
Like it says on the link posted by dugas, shelvesets are built more for...well, shelving things. For example, on the project I am working on right now, I did a shelveset for some refactoring changes I was in the middle of because something unrelated broke and I needed the code back to the original non error-filled version. I also use it for when I'm in the middle of attempting something and want to have a backup but I don't want to check in code just yet.
There's no versioning on shelvesets, but it is possible to compare code in a workspace, to the code in a shelveset, without pulling the shelveset files.
Pull the versions of files you want to compare the shelveset contents to, into a workspace
open the solution in that workspace
File >> Source Control >> Unshelve Pending Changes...
find the desired shelveset and bring up its details
On each file in the Shelveset Details window, you can right-click and select Compare >> With Workspace Version...
TFS will pull the shelveset file to a temporary location, show the diff, and then (?) clean up the temp file after you're done.
You'll be comparing the shelveset file contents, to the contents of the files on the local disk in this workspace. If changes were made to both files, the compare won't be able to tell and will indicate all those changes. However, you can compare the selveset version to its original (Compare >> With Unmodified Version..), to see all the changes that were made just to the shelveset file. You can also find out the changeset that was the base for the shelveset file (Properties..), and see what changes were added to the workspace version since that common base changeset.
There's no tree compare though, and this may require the TFS power tools to work.
P.S> I don't recomment trying to use shelvesets in place of checkins like this. If there's one thing I've learned over the years, it's not to fight Microsoft's designed-in workflows -- you do things their way, or you find a different tool. Microsoft doesn't intend you to use shelvesets this way (they want you to use changesets and a branch), and if you try, you'll constantly be fighting Microsoft's designed-in workflow.
You can use shelvesets for peer code-review before committing them to the repository ... and also for parking commits before going through a gated build process.
They are not suitable for anything other than "quick shelving" of work - use branching if you want to have multiple parallel work streams.