建立Subversion版本库的建议

我们的团队正在努力通过SVN来使用源代码管理。我们目前正在使用一些测试库来习惯这个过程。建立Subversion版本库的建议

我们几乎已经准备好将它用于全职使用。

我们只建小到medum /大型Web应用程序，其中大部分共享相同的核心（但不同的充上LAMP /运），但在某些方面进行定制。我们可能会在数据库中有数百个项目。另外，我们通常为一个组织执行多个项目。

我们有LAMP和Windows开发人员。（我认为这使得问题比Best practice for creating subversion repositories?有所不同）

你对如何构建资源库有什么建议？

来源

2009-07-09 ScottE

我实际上认为使用Linux和Windows开发者根本不会改变您链接到的问题。所有这些答案都适用。（这是源代码控制点之一 - 它与你的客户端操作系统无关！） – 2009-07-09 12:58:32

如何构建您的回购可能很大程度上取决于发布周期。当你做一个新的通用核心版本时，你会立刻把它推出给所有的客户吗？或者，您是否会逐渐推出，因为每个客户都需要新功能（因此需要核心中的新功能）？

如果你推出给大家，当你升级你的核心，那么你可能需要一组分支/标签/主干：

branches/ 
tags/ 
trunk/ 
    core/ 
    customer1/ 
     project1/ 
     project2/ 
    customer2/ 
     project1/ 
     project2/

这样做的缺点是，如果有很多的代码为每个客户，你的结账将是巨大的，你必须检查一切能够做任何事情（虽然svn 1.6确实让你能够检查出树的一个子集）。另一方面，如果不同的客户将按不同的时间表发布，那么您可能更愿意为每个客户设置一个顶级目录。你也希望某个地方保持你的共同核心。

core/ 
    branches/ 
    tags/ 
    trunk/ 
customer1/ 
    branches/ 
    tags/ 
    trunk/

如果你这样做，你可能想看看svn:external所以你得到的公用核的副本，只要你看看customer1表的源代码树。不过，这会在您想要分支或标记时导致一些问题。（这可能是选择第一个选项的原因。）

如果您还没有，请阅读“Pragmatic Version Control Using Subversion”。他们有一些使用外部的例子，这可能有助于澄清你想要使用的方案。

来源

2009-07-09 13:02:16

我认为单个存储库（备份，当然）与个别项目目录下面应该足够了：

/usr/share/code_repository 
    /base 
     /trunk 
     /branches 
     /tags 
    /project1 
     /trunk 
     /branches 
     /tags 
    /project2 
     /trunk 
     /branches 
     /tags 
    ...

所以基地的核心代码和PROJECT1，项目2，... projectN将包含基地的变化。当你签出projectN时，你也可以在Project1中签出基础并链接到base。

这样做的另一种方法是简单地有一个与其中的核心回购，并为每个变化做一个分支。也就是说，如果核心是一个，大块和你的变化实际上只是变化。

与版本控制结构相比，这看起来更像是代码打包体系结构的问题。

来源

2009-07-09 12:50:30

这是我喜欢的方式，因此每个项目都有其独立的标签/分支。 – 2009-07-09 12:54:55

SVN是否维护每个存储库或每个项目的修订号？通过这种布局，project2中的版本号不会更改project1中最新的编号？ – 2009-07-09 13:05:44

组织/项目是否合理？正如我所说，我们有很多项目。 – ScottE 2009-07-09 13:18:56

正确的答案是“无论什么最适合你”。

有人会告诉你这种方式的优点，但在一天结束时，有项目 - > {干线，标签，分支机构}或{干线，标签，分支机构} - >项目，或者如果您拥有发布分支，或者将这些分支重命名为其他任何项目，或者在其中具有其他指定项目，或者删除某些指定项目，都取决于您和您的同事的工作方式，以及您的开发周期最适合的项目。

然而，从你说的话，我建议如下：

repository 
    core 
     trunk 
     branches 
     tags 
    project1 
     trunk 
     branches 
     tags 
    project3 
     trunk 
     branches 
     tags

这样做的好处是，你将能够将每个项目链接到不同版本的核心，这将是内部的核心/标签文件夹，同时仍然允许开发核心。这只是我的建议。你的心态可能不同

来源

2009-07-09 12:51:07 Xetius

创建不同的项目作为不同的存储库（在同一台机器上）。以便您可以分别控制每个项目的更改邮件列表:)

来源

2009-07-09 12:51:38

这是一个主观问题，因此您可能需要修改标签。

假设你在问开发项目，你必须弄清楚你正在做什么样的开发。不同的语言或项目类型通常会导致不同的“标准”。

从CVS继承的传统SVN结构是让trunk,branches和tags坐在主工程目录中。这将会为每个单独的项目目录重复。

对于相互依存的项目，我个人比较喜欢

root/somepath 
    trunk 
    myproject 
    branches 
    branch1 
     myproject 
    branch2 
     myproject 
    tags 
    tag1 
     myproject 
    tag2 
     myproject

这使得更容易检查出标记有相同的标签/分支的所有项目。

但它高度依赖于您的构建脚本以及您计划让开发人员或用户签出的方案。什么是最好的是你的项目是合乎逻辑和高效的。

来源

2009-07-09 12:55:24 aberrant80

颠覆的伟大之处在于，你一开始并不需要太在乎那么多。

由于您可以在存储库内移动文件和文件夹而不会丢失历史记录，因此您可以从任何您认为正确的内容开始，并查看它是否适用于您。

如果没有，它可以在以后更改没有太多问题。

来源

2009-07-09 13:05:48

建立Subversion版本库的建议

回答

相关问题