Submerged中文版|Subversion专家Blog

我前一个blog中讨论了版本库的布局，这个条目会尝试回答是选择单版本库单项目还是单版本库存放所有项目的问题，这里没有一个唯一的正确答案，但希望本文可以帮助你理解代价，你才可以做出正确的决定来满足你的需求，下面是单版本库方法的优点：

1. 管理简单，只需要部署一组钩子，备份一个版本库等等。
2. 分支/标签灵活性，因为所有的代码在一个版本库，这样可以容易的创建跨多个项目的分支或标签。
3. 移动代码更简单。你或许希望把代码从一个项目移动到另一个，或者将其作为多个项目的库，这样可以容易的将代码在同一个版本库移动，并保持代码的历史。

下面是单版本库的缺点，以及多版本库的优点。

1. 大小。对付多个小版本库会比对付一个大版本库容易，例如你结束了一个项目，你只需要归档版本库到媒介，然后从磁盘删除并释放空间。也许因为某些原因你需要转储/导入版本库，例如利用新的Subversion特性，如果库很小，会很容易做且影响很小，即使你最终希望对所有的版本库作这些事，也比一次完成的影响小，当然我们假定没有急迫的需要一次完成这些任务。
2. 全局修订版本号。即使这不应该是一个问题，一些人还是要求使用一个修订版本号，不希望来看到版本库修订版本号的自己增加，造成修订版本历史的横沟。
3. 访问控制。Subversion的authz机制允许你根据版本库的部分需要限制访问，如果你有一个项目，只有一些选定的人可以访问，对于一个版本库，这样做很简单。
4. 管理灵活性。如果你有多个版本库，可以根据版本库/项目的需要实现不同的钩子，如果你希望统一钩子脚本，单个版本库会更好，但是如果每个项目希望自己的email样式，在不同的版本库中实现会更容易。

这里只是每种方法的赞成和反对意见，希望它可以帮助你做出决定，我更喜欢一个版本库一个项目的方法，如果我有多个项目互相关联，我会喜欢多项目单版本库的方法，我也希望通过组或团队分离版本库，尽管实际上是项目概念的变种。

例如，我有一个文档部门项目使用的版本库，当然，在这个例子里在线帮助经常与应用代码位于一个相同的项目，但是文档组也有他们制作的其他材料，我们给了他们另一个版本库。同样的，市场部也有一个版本库存放他们需要的东西，例如公司网站。因为我们讨论版本库的布局，这是可以最好工作的决定，也可以说，在设置好后，改变版本库可能会或多或少有点麻烦。

所以，很值得花时间理解需求来决定哪种方法更适合他们。

原始链接

About the Author

Mark Phippard is Director, Subversion Engineering at CollabNet. He works on the CollabNet Subversion team and is a project owner for the Subclipse project as well as a partial committer for Subversion.

Technorati : CollabNet, Open Source, Programming, Revision control, SCM, Software Configuration Management, Software development, Sourceforge, Subversion, Version control, rocksun, www.subversion.org.cn

很荣幸参加了最近Subversion 1.5合并跟踪中关于分支与合并的webinar，第一个webinar名字为” Branching and Merging Strategies for Subversion 1.5“，关注的是分支和合并模型，第二个，” Advanced Merge Tracking and Branching with Subversion 1.5“，则关注于在第一次webinar中读者的问题，两次的目的都是提供一些关于企业应用中很重要的实践信息的主题，但是并没有很好的覆盖Subversion到底有什么能力。

我希望发布一些第二次webinar上的问题和回答，我希望这能有用且能够鼓励你重放webinars来学习更多（http://www.collab.net/webinar21和http://www.collab.net/webinar22）。

如果安装1.5服务器，可以让服务器拒绝1.4客户端的请求来保证合并跟踪吗？

一个潜在的方法是开发是pre-commit钩来拒绝1.5之前客户端的提交，但现在还只是讨论，并没有保证会实现。我想起了users.subversion.tigris.org邮件列表中的一些有趣的讨论，这些场景通常包括一个进程和一个服务器升级，来确保你的环境，所有的特性可以被所有用户访问和利用，Subversion社区制作升级服务器，并且客户端需要直接确保指向的发布不会出现问题，在你希望新功能使用的完整时，你会得到进程的辅助。那是合并跟踪特性没有钩子时的回答。

每个文件的的完整拷贝都存放在版本库吗？

不是，Subversion使用二进制区别算法识别和存储修订版本的区别，这是简单的答案，但是还有很多故事。Subversion使用跳过区别方法来提供每个修订版本文件的快速访问，跳过区别是在检索文件任何修订版本时的一种确保只有部分区别需要组合的技术，解释起来有一点复杂，如果你对跳过区别的实现感兴趣，可以阅读官方的 文档（March ‘07 openCollabNet Technical Newsletter）。

你有捕获每夜发布快照进行测试的策略吗？

我想使用修订版本号码或时间都很适合执行此类快照的构建，标签（tags）只是用来其他人需要能够跟踪构建到源程序或在将来你自己需要。

第三方工具需要改变来支撑新的合并跟踪吗？

简短的回答是”不”，因为这些功能可以看作是通过标准的merge操作，log和blame。也就是说，可以肯定的是以更用户友好的方案利用这个核心功能，另一方面，我们在我们的CollabNet Desktop - Eclipse Edition添加了特定功能，来帮助”合并管理“以及与命名的修改集关联，我期待着其他对于合并跟踪功能扩展的出现。

一个有些重复的问题：”有修改集的概念并可以基于之上合并吗？”

一个Subversion的基础特性就是原子提交定义的修改集，合并跟踪提供了优选特定修订版本作为合并的源，这个合并就是到目标分支中与修订版本关联的特定修改集，如果目标修改集没有限制为一个单独的修订版本，一个解决方案就是与问题管理工具关联，修改集关联到一个问题，例如CollabNet的修改集合并可以与CollabNet/SourceForge企业版一起使用。

你能提供一个svnmerge客户端和1.5核心功能的高级别比较吗？

通常情况下，1.5提供了对于svnmerge.py更广泛的支持，而一些svnmerge.py特性，例如修订版本阻塞将会出现在Subversion以后的版本，而不会出现在1.5，更广泛的支持包括：

• 支持每路经而不是branch级别的粒度。
• 对于svn:mergeinfo属性的合并修改作为后续作的合并或修改。
• 支持普通客户端，相对于使用客户端以外的工具。这样给了我们更加详细的审计工具。

1.5合并跟踪可以使用svnmerge.py的数据吗？

1.5会提供移植脚本，允许你将svnmerge的数据移植到新的核心方案中，这个脚本利用了移植数据的转换将客户端方法的svnmerge转化为核心方案。一个用户可以选择对整个版本库或特定路经执行移植，这意味着你现在可以使用svnmerge来减轻管理跟踪合并的负担，也可以将数据带到以后，这样合并跟踪可以审计1.5安装之前的合并。

在我发布一些关于第三次基本分支策略讨论的内容之前，我会给你机会至少看一下第一次webinar的回放。

原始链接

About the Author

Bob works (> 5 years) for CollabNet Services, Marketing or whomever needs an opinion. He has been focused on the delivery of version control and SCM for more than 10 years with the last three making people successful with Subversion. He helps CollabNet identify what our engineers should focus on with the Subversion open source project based on his experience, customer feedback, and his own prejudices.

Technorati : CollabNet, Open Source, Programming, Revision control, SCM, SVN, Software Configuration Management, Software development, SourceForge, Subversion, Version control, rocksun, www.subversion.org.cn