首先，我看了以下几页并且没有得到我的答案： 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章。
他们都有很好的建议，但我很难将其与我的需求联系起来。
基本上，我想组织我们的Web服务器的代码。我们有$ WEBROOT / htdocs和$ WEBROOT / cgi-bin。在我们的htdocs目录下，我们有$ WEBROOT / htdocs / js和$ WEBROOT / htdocs / css用于java脚本和样式表。
我们的“项目”不是真正的项目，而是一小段代码 - 可能是Perl脚本，java脚本文件和样式表。我们可能有大约一百个这样的小“项目”，它们几乎都是相互独立的，但都存在于同一个Web服务器上的同一个$ WEBROOT中。
我们的代码还没有进行颠覆，但我希望它是 - 我只是无法有效地组织它。如果需要，我们可以有多个svn存储库，但如果每个存储库只有3-10个元素，那对我来说似乎是一种浪费。
我认为可行的是这样的：如果我编写一个脚本来计算Web服务器上正在运行的进程（为了示例）。假设我有一个perl脚本，一个js文件和一个css文件。我可以将“project”命名为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下面是我的Web服务器上的所有代码，在这两个目录中：
htdocs
cgi-bin
最大的缺点是，对于1个元素的小代码更改，我将不得不检查我的Web环境中的每一段代码。好处（有点）是我可以在我们的网络服务器上进行“svn更新”，以获取提交给存储库的任何更改。
也许我只是让它变得比它应该更复杂，但有没有人对如何在subversion中有效地组织我的代码有任何建议？
非常感谢提前！
布赖恩
答案 0 :(得分：5)
我认为您通过为许多项目保留单个存储库来进行正确的调用，因此我只会对您的部署过程进行更改：
你的svn回购看起来像（你的第一个选择。）
/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
如果要部署，请使用脚本将文件复制到应该部署的位置。
通过这种方式，您可以保留一个人工障碍（文件夹），以便在项目之间组织您的想法，而不仅仅是一大堆文件。
编辑：意外保存＆amp;为清晰起见添加了其他目录
答案 1 :(得分：1)
我认为你最好的选择是第二种选择：在htdocs和cgi-bin目录的单一回购下使用所有代码。确实，您必须检查所有代码，但是您只需执行一次，其余更改将会更小。如果它是一个生产服务器，你显然需要检查所有代码是否已准备好生产：保持树干绿色，可以这么说。
将来它可能有助于消除重复的功能。
答案 2 :(得分：1)
由于您尚未提交Subversion，请考虑使用Bazaar。它特别适合许多小项目的版本控制，因为它的设置开销非常小。
答案 3 :(得分：1)
首先，使用单个存储库。有关单个存储库可以扩展的程度的示例，请查看Apache svn repository。 Everything 是一个存储库。
如果您使用直接部署到网络服务器上的单个中继线，那么您需要确保中继线保持部署准备就绪。这意味着所有的开发应该首先发生在一个被合并回来的分支上。你不希望最终出现一个项目是半完成但是在trunk中而另一个项目需要在trunk中进行bug修复部署的情况。
我不担心要求人们检查整个主干，但如果这是一个真正的问题，那么你可能会考虑采用混合方法：
/svnrepo/trunk/project1/...
/svnrepo/trunk/project2/...
/svnrepo/deploy/htdocs
/svnrepo/deploy/cgi-bin
在这种情况下，开发人员必须从他们在trunk中的项目到deploy目录中的适当位置执行svn copy。然后，您可以自动释放deploy下的所有内容。