Git 或 Mercurial 是否可以设置绕过本地存储库，直接进入中央存储库？
使用 Git 或 Mercurial，如果工作目录是 1GB，那么本地存储库将是另外 1GB（至少），通常驻留在同一硬盘驱动器中。然后当推送到中央存储库时，还会有另外 1GB。
Git 或 Mercurial 是否可以设置为仅使用工作目录，然后使用中央存储库，而无需拥有此 1GB 数据的 3 个副本？
（实际上，当中央存储库也更新时，那么同样的数据就有4份...可以减少吗？在SVN场景下，当有5个用户时，那么就会有6GB使用分布式版本控制，那么会有 12GB 的数据？）
更新：这很奇怪 - 我只是尝试查看我使用 Mercurial 克隆的项目：工作目录不包括.hg 文件夹为 126MB，但 .hg 文件夹为 239MB。它是一个新的克隆...是因为我的新存储库实际上包含所有历史记录/修订，所以这就是为什么它的大小是工作目录的两倍？
Using Git or Mercurial, if the working directory is 1GB, then the local repository will be another 1GB (at least), residing normally in the same hard drive. And then when pushed to a central repository, there will be another 1GB.
Can Git or Mercurial be set to use only a working directory and then a central repository, without having 3 copies of this 1GB data?
(actually, when the central repository also update, then there are 4 copies of the same data... can it be reduced? In the SVN scenario, when there are 5 users, then there will be 6GB of data total. With Distributed Version Control, then there will be 12GB of data?)
Update: it is strange -- I just tried to look at a project I cloned using Mercurial: the working directory not including the .hg folder is 126MB, but the .hg folder is 239MB. And it is a new clone... is it because my new repository actually contain all the history / revisions, so that's why it is double the size of the working directory?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Git 或 Mercurial 是分布式版本控制系统。这意味着每次结帐都包含项目的整个历史记录。绕过这个就会破坏使用 DVCS 的全部目的（每个操作都可以离线完成）。
但总的来说，Mercurial 或 Git 具有非常高的压缩比，即使它们存储整个历史记录，通常也比 svn 更好。
Git or Mercurial are distributed version control systems. This means that every checkout contains the whole history of the project. Bypassing this would defeat the whole purpose of using a DVCS (every operation can be done offline).
But in general Mercurial or Git have a very high compression ratio, often better than svn even if they store the whole history.
hg clone 在 unix 文件系统上创建硬链接，因此只有新更改集引入的更改才会使用存储中的空间。当您不需要工作副本时，可以将存储库更新为“空”修订版，该版本仅包含存储库而没有工作副本。
Git 还可以选择裸存储库和共享存储库，但我从未尝试过。
hg clone create hard links on unix file systems, so only changes introduced by new change sets use space in the storage. When you don't want a working copy, you can update the repo to the 'null' revision, which consist only of the repository without working copy.
Git also has the option of bare repositories and shared repositories, but I never tried them.
只要您拥有安装了“中央”存储库并可在本地访问的文件系统，您就可以执行您所要求的操作。
来自 cmd.exe：
您可以根据需要执行此操作以进行任意多次结账，但这并不是很理想。确实，git 在 Windows 上的工作不如在 Linux 上工作得那么好 - 理想的解决方案是每个克隆都具有指向对象的硬链接，因此它们仅在磁盘上物理存储一次，然后每个克隆都可以例如，可以签出到不同的分支，这样您就可以同时跟踪开发/测试/生产。
另外，就您对磁盘使用情况的担忧而言，请尝试在您的存储库之一上执行 git gc --aggressive --prune ，看看它是否仍然占用大量空间。根据我的经验，git 非常适合仅存储二进制增量 - 我通过将一个充满 MP3 文件的目录添加到存储库并提交它们，更改 ID3 标签，然后提交更改，以及在运行
git gc.git 文件夹中显然每个 MP3 都有两个副本，但是在git gc之后，大小又回落到仅比原始工作目录稍大一些。You can do what you're asking as long as you have the filesystem with the "central" repository mounted and accessible locally.
From cmd.exe:
And you can do this for as many checkouts as you want, but it's not really ideal. It's true that git doesn't work quite as well on Windows as it does on Linux - the ideal solution is for each clone to have hard links to the objects, so they're only physically stored on disk once, and then each clone can be checked out to a different branch, so you could track development/testing/production all at once, for example.
Also, as far as your concerns about disk usage go - try doing
git gc --aggressive --pruneon one of your repositories and see if it's still taking up a huge amount of space. In my experience, git is very good about storing only binary deltas - I have tested this by adding a directory full of MP3 files to a repository and committing them, changing the ID3 tags, and then committing the changes, and before I rangit gcthere were clearly two copies of each MP3 in the .git folder, but after thegit gcthe size went back down to just slightly larger than the original working directory.