/反对使用svn进行部署的原因？

Question

所以，

在我的工作中，我们使用svn来管理我们的源代码，但是在部署时，我们使用正在生产的代码执行svn导出和rsync。这是我开始以来的方式（这是我的第一个编程工作）以及我们如何继续做事。

我开始在工作之外开始自己的个人项目，仍然使用svn来管理我的代码 - 但是，我只是在服务器上执行结帐，而不是使用服务器上的树同步导出。当我滚动新代码时，我就开始了。这对我来说似乎更简单。

有没有充分的理由不在生产机器上使用svn？我忽略了安全隐患？

Answer 1

我可以想到几个问题：

• 服务器上的checkout将在那里创建不必要的.svn目录
• 要在服务器上签出，用户需要SVN和服务器访问权限

这些都是我的头脑 - 我相信还有更多。

Answer 2

svn checkout大约是导出数据大小的2倍，因为.svn文件夹包含用于在出错时恢复的数据。导出不会创建.svn文件夹，因此可以使用更少的空间。

Answer 3

我认为Svn的部署是可以的。如果您的服务器安装了客户端，并且它的步骤少于导出和rsync，那么这很容易。

我能看到的唯一问题是一些不支持它的廉价托管服务提供商，而且svn客户端可能会存储您用来检查代码的帐户，可能允许其他人访问。

Answer 4

• 服务器上的额外负载
• 对您的prod环境的更改意味着对您的开发基础架构中不相关的方面的干扰，反之亦然。一个问题扰乱了另一个。
• 挑战管理角色和权限。 Neil需要svn和服务器帐户的例子就是一个例子。管理适当的文件系统访问控制是另一个（整个团队是否应该对生产目录具有写权限？）。

简而言之，在服务器上使用svn会在dev和prod之间引入更紧密的耦合，这会导致与代码的不同部分之间的紧密耦合没有太大差异的问题。

Answer 5

第一个想法：如果发生攻击，攻击者现在也可以访问您的源代码。

Answer 6

您将在.svn目录中的Web上提供源代码，这可能是个问题。

这正是我们对phc的处理方式，您可以access the .svn files作为结果。但是既然它是开源的，那没关系。

当然，您可以使用.htaccess文件修复此问题。

Answer 7

如果你不想在你的www直播目录中有.svn文件夹，并且仍然使用更新而不是导出，因为它是紧固的，只需将你的www存储库签出在一个名为predeployfolder的不同文件夹中。

每次要将当前的HEAD存储库版本传输到live www文件夹时，请在predeployfolder中执行快速svn更新，然后在predeployfolder和live www文件夹之间进行重新同步，并指定.svn文件必须像那样被贬低：

rsync -az --eclude="*.svn*" predeployfolder wwwlivefolder