5

首先,我查看了以下页面并没有完全得到我的答案: how-would-you-organize-a-subversion-repository-for-in-house-software-projectshow-do-you-组织你的版本控制存储库

我还查看了使用 Subversion 的实用版本控制的第 8 章。

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

基本上,我想为我们的 Web 服务器组织代码。我们有一个 $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

在主干下将是我的网络服务器上的所有代码,在这两个目录中:

htdocs
cgi-bin

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

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

提前谢谢了!

布赖恩

4

4 回答 4

5

我认为您通过为您的许多项目保留一个存储库来做出正确的选择,所以我只会对您的部署过程进行更改:

您的 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

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

这样,您就可以在项目之间建立一个人为的障碍(一个文件夹)来组织您的想法,而不仅仅是一堆乱七八糟的文件。

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

于 2009-02-09T18:20:09.273 回答
1

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

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

于 2009-02-09T18:19:58.183 回答
1

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

于 2009-02-09T18:25:01.727 回答
1

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

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

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

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

在这种情况下,开发人员必须svn copy从他们的项目中的主干到部署目录中的适当位置进行操作。然后,您可以自动释放deploy.

于 2009-02-09T18:45:51.617 回答