Git与TFVC在TFS SQL Server数据库中的空间占用差异咨询

Great question—let’s dive into how these two version control systems handle storage in TFS’s SQL databases, and whether switching to Git could ease your SQL Express space crunch.

Core Storage Mechanisms #

TFVC’s Approach #

TFVC is a centralized system that stores every change incrementally in the SQL database, but with some key caveats:

• It retains full version history for every file, including all incremental changes and metadata (like check-in comments, work item links, workspace mappings, and permissions) directly in SQL.
• For large files or frequent changes, even small edits can add up over time—each incremental change is tracked separately, and the database accumulates both file version data and extensive metadata.
• There’s no built-in deduplication for identical file content across branches or versions, so if the same file exists in multiple branches, it’s stored multiple times.

Git’s Approach #

Git uses a content-addressable object model, which translates to much more efficient storage in TFS’s SQL database:

• Git stores files as "blobs," and identical content (even across different branches or commits) is stored only once. If you have a file that’s unchanged across 10 commits, Git reuses the same blob instead of storing a new copy each time.
• All Git objects (blobs, trees, commits) are automatically compressed, and TFS runs periodic garbage collection (git gc under the hood) to clean up unused, unreferenced objects (like abandoned branches or stale commits), further reducing space.
• Most client-side Git metadata (like local commits, unpushed changes, or local workspaces) never touches the TFS SQL database—only the shared remote repository content and core server-side metadata (branches, tags, commit history) are stored there.

Real-World Space Comparison #

In most cases, Git will take up less space than TFVC in your TFS SQL database, especially if your team:

• Works on projects with lots of repeated file content (e.g., shared libraries, assets used across branches).
• Makes frequent small edits to files (Git’s deduplication shines here).
• Has a long history of branching and merging (TFVC stores branch-specific version data separately, while Git’s object model consolidates shared content).

That said, if your team primarily works with large files that change drastically in every commit (e.g., uncompressed media files), the space difference might be smaller—but Git’s compression will still give you an edge.

Practical Next Steps #

If you’re tight on SQL Express space (10GB limit per database for recent versions), here’s what you can do:

1. Test a small migration: Pick a medium-sized TFVC project, migrate it to Git in a test TFS collection, and compare the database size before/after. This will give you concrete numbers for your use case.
2. Trim history during migration: If full historical access isn’t critical for all projects, you can migrate only the most recent commits (e.g., the last 6 months) to drastically reduce initial storage.
3. Enable Git garbage collection: TFS usually runs this automatically, but you can trigger it manually via the TFS Admin Console to clean up unused objects immediately.

内容的提问来源于stack exchange，提问作者user3574474