问题 Subversion在哪里实际存储其DataBase?


在阅读了很多关于SVN的介绍,入门指南和文档之后,我仍然无法弄清楚我的版本控制数据存储在哪里。我的意思是身体。我结束了 编辑 检入[1/2 GB]代码,并且repo只有几MB大。这对我来说仍然是伏都教。而且,作为一名程序员,我并不真的相信魔术师。

编辑:  贡献者表示并非所有代码都存储在回购中,是真的吗?我的意思是,如果我删除我的本地工作副本,我仍然可以取回我的存储库的源代码... 如果是这样,我仍然无法理解如何在我的代码上发生这样的压缩......

编辑2:  当我将代码导入存储库时,我有“50MB上传”的消息,实际的回购要小得多。必须参与压缩算法。

顺便说一句,阅读一些答案,看看有多少人确实相信魔术,并且在没有真正使用SVN的情况下知道幕后发生了什么,这很有趣...


12107
2018-01-17 19:54


起源

你真的有10 GB的代码吗?这是一大堆代码,可能比进入MS Windows的所有源代码都要大。我根本不相信这个尺寸。 - abelenky
物理位置是数据库所在的计算机所在的位置...... - JasCav
有多少人错误地回答这个问题,我感到很惊讶。 .svn文件夹不是服务器存储其文件的位置(因为它是机器的本地文件 - 没有其他人能够检查该信息),并且,虽然SVN只存储差异(假设FSFS),但它必须存储原件SOMEWHERE。 - JasCav
我的猜测,70%是perf数据,另外29.99%是'obj'和'bin'目录。留下您签入的10mb实际代码;) - csharptest.net
@Mika - SVN使用了大量压缩算法和各种技术,并不一定将数据字节存储在存储库中。这可能就是你看到尺寸差异的原因。 - JasCav


答案:


根据Mika的要求,将此作为答案:

有多少人错误地回答这个问题,我感到很惊讶。 .svn文件夹不是服务器存储其文件的位置(因为它是机器的本地文件 - 没有其他人能够检查该信息),并且,虽然SVN只存储差异(假设FSFS),但它必须存储原件SOMEWHERE。

当然,正如@ csharptest.net所说:“我的猜测,70%是perf数据,另外29.99%位于'obj'和'bin'目录中。留下你签入的10mb实际代码。”所以你实际上并没有真正检查所有这些信息。其中大部分从未进入存储库。此外,SVN使用了大量压缩算法和各种技术,并不一定将数据字节存储在存储库中。这可能就是你看到尺寸差异的原因。

如果您有兴趣阅读有关SVN如何工作的更多信息,请阅读此内容 Stackoverflow的答案

希望有所帮助!


6
2018-01-17 22:13



谢谢Dude,这很有见地 - Mehdi LAMRANI


这取决于您用于Subversion服务器的内容。我用 VisualSVN服务器,它将存储库文件保存在c:\ Repositories中。


7
2018-01-17 19:58



是的,这也是我使用的......我的自定义E:\ SVN repo只有几MB - Mehdi LAMRANI


您的svn存储库存储在文件系统的一个文件夹中,它应该包含子文件夹,如: conf, dav, db, hooks, locks。这些文件夹组成了存储库。

有一个 svnadmin的 可用于管理存储库的工具。


3
2018-01-17 20:00





它存储在文件系统中。究竟在哪里取决于系统的设置方式。此外,在创建新存储库时,它可以位于文件系统的任何位置。您的安装将具有默认位置,但是可以在任何地方创建新的仓库,您是否可能需要环顾四周才能找到实际路径。

这是在命令行版本中完成的,如下所示:

svnadmin create d:/path_to_repository 

在上面的示例中,存储库存储在“d:/ path_to_repository”中

另外,在查看本地计算机中的代码块时,是否过滤掉了不进入服务器的内容?您应该有一个全局忽略列表,以排除源代码管理中没有业务的项目。 (用户更改的内容,通常是已编译的项目等)您可能高估了存储库的实际大小。


1
2018-01-17 19:57



是的我正在过滤70%的源代码文件夹内容,但仍然......从3GB到几MB是非常令人惊讶的 - Mehdi LAMRANI


你为什么不查看一个新的工作副本,在那里建立,并验证一切仍然有效?我们都可以在这里写出答案并猜测有多少%可能在哪里,但最后,您仍然应该检查需要添加到Subversion的所有内容。


1
2018-01-17 20:55



你是对的。在询问之前我通常断言这种情况,是的,我在其他开发者工作站上检查过,一切正常。 - Mehdi LAMRANI


我意识到这是一个较老的线程,但在阅读之后,我以为我会投入我的$ .02。

工作副本中的大型本地文件集的贡献因素是:

  • 如上所述,工作副本元/状态数据存在于隐藏状态(默认情况下) .svn 目录。虽然元数据非常小,但对于工作副本中的每个文件,都有一个工作副本基线。这将使存储在存储库中的任何文件所占用的磁盘空间加倍。

  • 如果您的存储库包含任何复制的路径(通常在分支或标记的情况下),您可能会使用多次物理空间。这是因为SVN存储库中用于“逻辑”副本的真实空间很小。它实际上只是指向源路径的特定修订版的指针。您可以使用复制操作复制整个存储库,从而导致新的存储库数据只有几百个字节(这也是为什么任何复制操作都需要相同的,短时间的原因)。然而,当您签出或更新工作副本时,它可能是您复制之前的两倍。这通常是为什么人们会使用切换操作将工作副本更改为逻辑复制路径的分支或标记,而不是从其根目录递归检出整个存储库。

我对SVN存储和传输其存储库数据的紧凑程度印象深刻。


0
2018-05-02 20:55





每个版本化文件夹中隐藏的.svn文件夹。


-2
2018-01-17 19:58



@Eric Gagnon:.svn用于客户端上的状态跟踪,而不是svn存储库本身。 - tawman
@Eric - 因为那不是存储库。它是元数据,但不是实际的存储库文件。 (在任何一种情况下,我都不是downvoter,但答案是错误的。) - JasCav
好的...我认为这就是Mika所要求的(“Subversion数据库”和“版本化数据”)。我当时误解了这个问题。 - Eric Gagnon
是的,你们都是正确的 - 如果OP希望看到它如何在幕后工作,那么他们可能希望安装一个svn服务器 - 例如Visual SVN服务器(易于管理+免费)并亲眼看看:) - Maciek