组织许多小项目的颠覆存储库的最佳方式

Question

首先，我查看了以下页面并没有完全得到我的答案： how-would-you-organize-a-subversion-repository-for-in-house-software-projects 和 how-do-you-organize-your-version-control-repository

我也看过Pragmatic Version Control using Subversion的第8章。

他们都有很好的建议，但我很难将其与我的需求联系起来。

基本上，我想为我们的网络服务器组织代码。我们有一个 $WEBROOT/htdocs 和 $WEBROOT/cgi-bin。在我们的 htdocs 目录下，我们有 $WEBROOT/htdocs/js 和 $WEBROOT/htdocs/css 用于 java 脚本和样式表。

我们的“项目”并不是真正的项目，而是一小段代码——可能是 Perl 脚本、java 脚本文件和样式表。我们可能有大约一百个这样的小“项目”，它们几乎相互独立，但都存在于同一个网络服务器上的同一个 $WEBROOT 下。

我们的代码还没有被颠覆，但我希望它是——我只是在有效地组织它时遇到了麻烦。如果需要，我们可以有多个 svn 存储库，但是如果每个存储库只有 3-10 个元素，那对我来说似乎是一种浪费。

我认为可以这样工作：如果我编写一个脚本来计算网络服务器上正在运行的进程（为了一个例子）。假设我有一个 perl 脚本、一个 js 文件和一个 css 文件。我可以将“项目”命名为 webserver_processes，并将其签入存储库：

/svnrepo/webserver_processes/trunk

在树干下，我可以：

htdocs/html/webserver_processes
htdocs/js/webserver_processes
htdocs/css/webserver_processes
cgi-bin/webserver_processes

我在这个“项目”中没有任何静态 html 文档，但如果我有，它们会进入“html”目录。

我在这种结构中看到的好处是，我可以一次签出一个“项目”，而不会真正影响 Web 服务器上的任何其他内容。缺点（也许它不是真正的缺点）是部署。我必须一次从存储库部署 1 个项目。我看不出如何使用这种方法创建具有我的 $WEBROOT/htdocs 和 $WEBROOT/cgi-bin 结构的工作副本。

另一种选择：

我可以像这样创建一个 svn 存储库：

/svnrepo/webcode/trunk

trunk 下将是我的网络服务器上的所有代码，在这两个目录中：

htdocs
cgi-bin

最大的缺点是，对于 1 个元素的小代码更改，我必须检查我的 Web 环境中的每一段代码。好处（有点）是我可以在我们的 Web 服务器上执行“svn update”以获取提交到存储库的任何更改。

也许我只是让这变得比它应该的更复杂，但是有人对我如何在颠覆中有效地组织我的代码有任何建议吗？

提前非常感谢！

布赖恩

Answer 1

我认为您为许多项目保留一个存储库是正确的选择，因此我只会对您的部署过程进行更改：

你的 svn repo 看起来像（你的第一个选项。）

/svnrepo/project1/trunk
/svnrepo/project1/trunk/htdocs
/svnrepo/project1/trunk/css
...
/svnrepo/project1/branches/branch1
/svnrepo/project1/tags/blah
/svnrepo/project2/trunk
/svnrepo/project3/trunk

当您要部署时，请使用脚本将文件复制到应部署的位置。

这样，您就可以在项目之间设置一个人为的障碍（一个文件夹）来组织您的想法，而不是仅仅拥有一堆乱七八糟的文件。

编辑：为清楚起见，意外保存并添加了其他目录

Answer 2

我认为您最好的选择是第二种选择：将所有代码放在带有 htdocs 和 cgi-bin 目录的单个 repo 下。确实，您必须检查所有代码，但是您只需检查一次，其余的更改就会小得多。如果它是生产服务器，您显然需要检查所有代码是否已准备好生产：可以这么说，保持主干为绿色。

将来它还可能有助于消除重复的功能。

Answer 3

由于您尚未致力于 Subversion，请考虑使用 Bazaar。它特别适合许多小型项目的版本控制，因为它的设置开销非常小。

Answer 4

首先，使用单个存储库。有关单个存储库可扩展性的示例，请查看Apache svn repository。 一切都是一个存储库。

如果您使用直接部署到网络服务器上的单个主干，则需要确保主干保持部署就绪。这意味着所有的开发都应该首先发生在重新合并的分支上。您不希望最终出现一个项目半完成但在主干中，而另一个项目需要在主干中进行错误修复部署的情况。

我不担心要求人们检查整个行李箱，但如果这是一个真正的问题，那么您可能会考虑采用混合方法：

/svnrepo/trunk/project1/...
/svnrepo/trunk/project2/...
/svnrepo/deploy/htdocs
/svnrepo/deploy/cgi-bin

在这种情况下，开发人员必须在主干中的项目中将svn copy 发送到部署目录中的适当位置。然后您可以自动释放deploy 下的所有内容。