代码之家 › 专栏 › 技术社区 › Brent.Longborough

建议的Subversion存储库布局背后的原因是什么?

svn

Brent.Longborough · 技术社区 · 17 年前

Version Control with Subversion 为(单个项目)存储库推荐以下布局(由 this question ):

/trunk
/tags
  /rel.1 (approximately)
  ...
/branches
  /rel1fixes

与(也许)更注重过程的安排相比,这种安排的相对优点是什么?:

/development
  /current
  /stable
/qa (maybe)
  ...
/production
  /stable
  /Prod.2
  /Prod.1
/vendor
  /Rel.5.1
  /Rel.5.2

请注意,我正在考虑内部部署,而不是构建产品。

免责声明:虽然我是一个颠覆性的用户,但我从来没有在真实的生活环境中使用过它。

7 回复 | 直到 17 年前

bmdhacks 17 年前

建议的布局和建议的布局之间的主要区别在于,建议的布局在某种程度上是自我记录提交内容的位置以及行为的。

例如,在推荐的布局中,很明显所有新开发都致力于主干,并且大多数分支都是由主干构成的。而且,很明显您不应该向/tags提交任何内容。最后,可以安全地假定分支是真正的分支,其中可能包含特定于特定分支目的的更改。

对于建议的布局,有些事情不太确定。是/发展/稳定分支/当前分支?开发/稳定与生产/稳定的关系是什么?这些目录中的哪些是标签,哪些是我可以实际签入的?

当然,这种行为可以被记录下来,但是通过坚持每个人都使用的可接受的布局,你将有一个更容易的时间让新员工跟上工作的速度。

community wiki 4 revs Brent.Longborough 9 年前

我将尝试总结到目前为止的答案:

简单的

“经典”布局( 躯干/ + 分支机构/ + 标签/ )有优势的可成长的简单
后备箱(通常)是主要的开发线
分支机构参加特别会议复杂的发展需求子项目和发布后维修
标记是固定不变的标记帖子
这种经典的布局是众所周知的,所以你的开发人员跟上进度更快

可膨胀的

供应商产品开发融入你的发展 (也许是适应)可以,如果必须作为供应商处理分支(通常一个就足够了)
“过程”轴(如开发, 单独进行测试,使用时进行质量保证,以及生产)可由适当的分支或标记约定(取决于需要进行任何更改或允许在“开发”之外。
这些附加的分支集可以通过命名来处理约定,或附加的目录级别 标签/ 或 分支机构/ .

查看其他问题

我已将此作为社区答案;请随时纠正或扩展任何不足之处,对此我深表歉意。

Chris Upchurch 17 年前

您已经描述了存储库组织的两个非常标准的模型:dev test prod和trunk branch。埃里克·辛克在他的书中很好地描述了他们。 Source Control HOWTO . 需要注意的一点是,大多数人使用主干分支的方式是在发布给客户时为每个版本创建一个分支,然后这个分支就变成了维护分支。

我倾向于使用主干分支,因为它不需要将从开发到测试到生产的每一个变更都迁移。只需要迁移需要返回到维护分支的更改,或者从维护分支迁移到主干的错误修复。

然而,有一种情况是dev test prod可能更可取,那就是在Web开发中,发布给客户的版本的概念并不真正存在。在本例中,prod将是服务器上运行的任何东西,而代码正在开发和测试中工作,并不断迁移到应用程序中,而不是在一个大的块中释放。

andyuk 17 年前

我认为灵活性和避免歧义是你的答案。

通过使用版本号,您不会将自己绑定到部署该版本的位置。

例如,您可能拥有部署为开发的1.3版、测试中的1.2版和生产中的1.1版。如果需要,您可以轻松地为另一个版本添加另一个临时环境,而无需更改Subversion布局。

没有人能争论代码的1.1版本是什么,但是“生产稳定”版本是模棱两可的。

neu242 17 年前

无论何时处理真实的实时环境,您都希望开发人员能够尽可能轻松地理解您的存储库。这样做的一个好方法是遵循推荐的颠覆标准布局。

petr k. 17 年前

虽然我个人使用SVN手册中推荐的布局,但是如果您的布局更适合您,您可能不应该限制自己使用它。我会保留分支由于目录的用法和用途与名称非常清楚。除此之外,如果它对你有用的话,任何事情都会发生。

-1

jfm3 17 年前

我觉得你的计划很好,真的。你如何解释一个程序员自己在尝试某个东西的分支?也许像/development/jfm3一样?