颠覆项目结构?

如果出现需要,选项1可以更简单地拆分为不同形式的源代码管理,因此我更喜欢它。

在我看来,在第一个选项中管理项目范围的权限更容易。

这两种方法都很常见,尽管第一种方法更常见。

更常见的是为单独的项目设置单独的存储库——人们就是无法忍受在“他们的”存储库中有“不相关”的东西。

我个人选择了选项1。这是因为选项2存在以下相当微妙的问题:

使用选项2,工作副本通常与存储库结构匹配。这意味着您可以有效地签出整个副本(或其部分,但处于相同的常规结构中)。

当涉及到依赖关系时,这是一个问题,例如ProjectA&ProjectB引用库C,库中所做的更改与应用于2个项目的更改之间没有控制。一旦对libraryc的主干进行了提交,所有使用它的项目都会接受它。这样做的净效果是你害怕改变图书馆,因为它可能会破坏其中一个项目。

使用选项1,可以使用Externals将特定版本的库C引入到ProjectA&ProjectB中。事实上,如果需要,A&B可以使用不同的版本。

这意味着您可以随意更改库,然后控制何时将更改应用于项目-根据需要测试和更改代码,并知道您要升级到库的最新版本。如果升级存在根本问题,可以继续使用旧版本,直到修复库的问题。

另一种查看方法是,使用选项2,如果查看ProjectA的历史记录,则无法知道对库所做的更改何时影响项目。事实上,同一版本的ProjectA可能会在某一天工作,而不是在下一天工作,因为库被更改了。唯一能告诉你变化的历史记录的方法是查看完整的历史记录,它还包括ProjectF和LibraryX完全不相关的变化,使得你想要的有用信息很难看到。

在选项1中,ProjectA的历史记录中有一个修订,告诉它使用库的新版本。这种变化不会神奇地发生——当您明确地说要使用库的新版本时。这通常是一个更稳定的环境。

通过最近的cvs-to-svn转换,我们决定在这两者之间做些什么:在顶层将相关项目分组在一起,下面是主干/标签/分支,下面是项目。

这是因为,在这个地方,许多项目相互关联,并且经常被标记、分支等在一起。