Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

TFS Branching and Disk Space

I've been thinking over some branching strategies (creating branches per feature, maybe per developer since we're a small group) and was wondering if anyone had experienced any issues. Does creating a branch take up much space?

like image 737
ryan.rousseau Avatar asked Oct 06 '09 17:10

ryan.rousseau


People also ask

How does TFS Branching work?

Branching in TFVC uses path-based branches that create a folder structure. When you create a branch, you define a source, usually the main folder, and a target. Then files from the main folder are copied into your branch. As developers work, they are encouraged to forward integrate (FI).

How do I create multiple branches in TFS?

Go to the Source Control Explorer. Once the Source Control Explorer is loaded you will see a list of all the team projects that hopefully includes yours. Expand the node for your team project and you should see the list of current branches as in the following.

How do I change the latest changes from master to branch in TFS?

In the right-hand pane, find your mainline branch, right-click and select Merge... In the Target branch drop-down, select your dev branch. If you want a subset of all the changes in the mainline: Choose the Selected changesets radio button, click Next.


2 Answers

Last time I looked, TFS uses copy-on-write, which means that you won't increase disk space until you change files. It's kind of like using symlinks until you need to change things.

like image 88
Jim Deville Avatar answered Oct 04 '22 03:10

Jim Deville


James is basically correct. For a more complete answer, we need to start with Buck's post from back in 2006: http://blogs.msdn.com/buckh/archive/2006/02/22/tfs_size_estimation.aspx

Each new row in the local version table adds about 520 bytes (one row gets added for each workspace that gets the newly added item, and the size is dominated by the local path column). If you have 100 workspaces that get the newly added item, the database will grow by 52 KB. If you add 1,000 new files of average size (mix of source files, binaries, images, etc.) and have 100 workspaces get them, the version control database grows by approximately 112 MB (60 KB * 1,000 + 520 * 1,000 * 100).

We can omit the 60KB figure since branched items do not duplicate file contents. (It's not quite "copy-on-write," James -- an O(N) amount of metadata must be computed and stored during the branch operation itself, vs systems like git which I believe branch in O(1) -- but you're correct that the new item points to the same record in tbl_Content as the source item until it's edited). That leaves us with merely the 520 * num_workspaces * files_per_workspace factor. On the MS dogfood server there are something like 2 billion rows in tbl_LocalVersion, but in a self-described small group it should be utterly negligible.

Something Buck's blog does not mention is merge history. If you adopt a branch-heavy workflow and stick with it through several development cycles, it's likely tbl_MergeHistory will grow nearly as big as tbl_LocalVersion. Again, I doubt it will even register on a small team's radar, but on large installations you can easily amass hundreds of millions of rows. That said, each row is much smaller since there are no nvarchar(260) fields.

like image 39
Richard Berg Avatar answered Oct 04 '22 04:10

Richard Berg