相关疑难解决方法(0)

当使用Subversion(svn)进行多个项目的源代码控制时,我注意到我的所有项目目录中的修订号都增加了.为了说明我的svn布局(使用虚构的项目名称):

    /NinjaProg/branches
              /tags
              /trunk
    /StealthApp/branches
               /tags
               /trunk
    /SnailApp/branches
             /tags
             /trunk

当我对Ninja程序的主干执行提交时,假设我已经将其更新为修订版7.第二天让我们说我对Stealth应用程序进行了一些小改动,它将作为修订版8返回.

问题是:在使用一个Subversion服务器维护多个项目时,是否普遍接受的做法是让所有项目中不相关项目的修订号增加？或者我做错了,应该为每个项目创建单独的存储库？或者它完全是另一回事？

编辑:我推迟了标记答案,因为很明显这两种方法都有原因,即使这个问题首先出现,我还是想指出其他一些最终提出同样问题的问题:

我应该将所有项目存储在一个存储库还是多个存储库中？

一个SVN存储库还是很多？

我知道在版本控制中至少有10种不同的方法来构建项目.我很好奇使用的方法是什么,哪些方法适合你.我曾与SVN,TFS以及目前/不幸的VSS合作过.我已经看到版本控制实现得非常糟糕而且很好,但从来都不是很好.

为了让球滚动,这里是对我所看到的事情的回顾.

此示例基于SVN,但适用于大多数VCS(与分布式版本控制无关).

1. 分支作为site/division/web/projectName/vb/src/[trunk | branches | tags]一部分的各个项目

2. 分支整个站点,在我看到的情况下,整个站点除了核心组件是分支的./部门/ [车厢|分支机构|标签] /网站/项目名称/ VB/src目录/

3. 使用main-line作为默认值,仅在必要时进行分支以进行大量更改.

当我第一次开始使用像CVS和SVN这样的修订控制系统时,我并没有真正理解"主干",分支,合并和标记的概念.我现在开始理解这些概念,并且真正了解它们的重要性和力量.

所以,我开始正确地做到了.或者我认为......这就是我到目前为止所理解的:代码的最新版本/稳定版本应位于/ trunk /中,而beta版本或前沿版本位于/ branches /目录内,作为每个beta的不同目录释放,然后在释放时合并到主干中.

对事物的看法过于简单了吗？你们推荐哪些存储库布局？如果它有所作为,我正在使用Subversion.