Question

我被告知大多数开发商店都有以下结构或者至少接近这个结构：

主存储库
- 每个Project文件夹都有一个trunk，branches和tags文件夹

这样：

ReponsitoryMain
    Project1
        branches
        trunk
        tags
    Project2
        ...

那为什么这更好或更好？如果你采取另一种方式，你会遇到什么或者有什么心痛？

Answer 1

大多数人这样做是因为Subversion book推荐的。

以下是CollabNet Subversion项目主管的一个很好的解释：

http://blogs.collab.net/subversion/2007/04/subversion_repo/

Answer 2

这种组织存储库的方式：

ReponsitoryMain
    Project1
        branches
        trunk
        tags
    Project2
    ...

当您的项目没有相互连接/相互依赖时，

是最好的。另一种方法可以更轻松地对整个项目套件进行版本控制。因此，如果您经常将Project1和Project2一起发布/打包，那么最好让它们共享同一个分支。

另一方面，如果您的项目非常分离并且有完全不同的团队在处理它们，那么您不需要在大多数时间一起检查它们，因此您可以使用上述方法。

Answer 3

存储库结构取决于您的需求。如果您的项目完全分离（它们之间没有依赖关系），那么这个“简单”的存储库结构就可以了。如果你的项目中有依赖项（例如一些全局“工具库”，共享代码），你应该使用不同的结构，如：

trunk
   prj_a
   prj_b
tags
   <YOUR_TAGNAME>
       prj_a
       prj_b
branches
   <YOUR_BRANCHNAME>
     prj_a
     prj_b

或其他任何对您的流程更有意义的事情。

在具有本地主干/标签/分支的简单结构中，如果您之间存在依赖关系，则无法（至少以干净的方式）标记多个项目。

此外，经常提出的“多存储库”方法也不会填补这一空白，因为在多个存储库中您注定了多个修订或标记。

主要问题是SVN 不支持共享资源并标记/分支它们。

如果您考虑一下您的存储库结构，您应该问自己在哪个过程中要共享您的代码库。

Answer 4

好的，我会更加快乐，并坚定地站在一个行李箱，标签和放大器的一边。每个项目的分支。

主要的选择是拥有一个主干，标签＆amp;分支与下面的所有项目。然而，这会导致许多问题，其中一个问题很重要，我将在此详述：

它主要为不可触及的图书馆铺平了道路，每个人都害怕接触某个特定的图书馆，因为任何改变都可能会在一些随机项目中打破一些微妙的东西。造成这种情况的原因是，由于项目之间没有分离，任何人都可以有效地更改项目中的代码，而无需检测或控制它。

有一天，你有一天检查你的项目并建立它，第二天你检查它并且它失败了，但是你已经对你的项目进行了无变化。发生的事情是有人改变了你所依赖的图书馆。在具有许多依赖关系的大型结构中，开发人员针对每个项目测试库更改是不现实的，特别是如果他们必须进行重大更改。您在项目中需要的是对特定版本库的引用。这样，只有在更改对最新版本的引用时，库才会更新。

这种引用有3种效果：1您的项目与库的随机中间开发更改隔离开来。 2您在项目中获得了一个修订版，它告诉您“我现在正在使用此版本的库”。 3.您可以控制何时对项目进行更改以解决库中的任何重大更改。

如果这还不够，还有其他问题我可以解决。

Answer 5

我们为每个项目保留一个单独的存储库。

虽然这不允许您将版本历史文件从一个项目复制并保存到另一个项目，但它允许您在项目结束时存档整个存储库。

Answer 6

这就是我们所拥有的。它起作用，现在已经足够好了（因为我们永远不知道未来会带来什么）我们没有任何令人信服的理由花费一些宝贵的时间（和金钱）来寻找可能更优化的结构。

微米。

Answer 7

在我的商店，我们有类似的东西：

RepositoryMain
  Trunk
    proj 1
    proj 2
    ..
  Dev
    Team1
      proj 1
      proj 2
    Team2
      proj 1
      proj 2
    ...

我不知道这是如何叠加到大多数地方，但似乎工作得很好

所有开发团队可以在他们自己的项目上单独工作，在开始开发/增强时从trunk到项目合并，然后在完成后合并回trunk。

Answer 8

Trunk分支和标签的行为方式相同。你如何使用它们取决于你。

我多年来一直在使用这种结构，并且尚未找到结构不能适应我需要做的时间。

Answer 9

在像CVS这样的系统中，你没有保留单独的“目录”。你只是标记和分支。

然而，SVN更多地建立在快照的概念上，因此非常有效地完成了东西的“复制”。不是标记或以其他方式标记项目的特殊（或替代）版本，而是更容易（并且更有效）制作它的命名副本。

Answer 10

感谢这里的讨论，我经历了这个和project-structure-for-product-with-different-versions

link2

link3

link4

我看到术语令人困惑。项目，应用程序，以正确关联

想用稍微明确的exp重复上述事情让我们说我们为客户ABC做解决方案解决方案是ABC的客户查询的TIcket / HelpDesk应用程序

让我们说applicationName是OneDeskApplication。该应用程序包括的 WebUI，共享库，构建工具

我们可以像这样设计SVN

XSoftware.com/ABC - 存储库 / 树干/ OneDeskWebUI OneDeskService OneDeskDBScript OneDeskBatchApp 分支机构/ Branch_Product_Support_1_0_0_0 / OneDeskWebUI OneDeskService OneDeskDBScript OneDeskBatchApp 标签/ OneDeskDocs OneDeskMasterBuild

SVN存储库结构 - 为什么这更好？

10 个答案: