Subversion 的标准实践 [英] Standard practices for Subversion
问题描述
我想知道使用 Subversion 的标准做法是否还有其他因素需要考虑.
I'm wondering if there's any other factors to consider for standard practice of using Subversion.
我拥有的几个是:
/tags/trunk 和/branches 的目录结构
Directory structure of /tags /trunk and /branches
所有工作都在不会破坏功能的主干中完成
All work is done in trunk which does not break functionality
在进行重大结构更改或添加破坏核心功能的功能时分支(取决于偏好)
Branch when major structural changes are made or when a feature is being added that breaks core functionality (subject to preference)
标签包含稳定版本
在开始工作之前总是执行更新
Always perform an update before starting work
在一天结束/添加功能时提交更改
Commit changes at end of the day / when a feature has been added
提交说明包含相关描述
根据功能提交 - 不要全面提交
Commit based on feature - don't blanket commit
我对在一天结束时和添加功能时提交的规则持不同意见.我在一天结束时说要确保存储库尽可能最新.然而，一天结束时的代码可能不完整/中断功能.但是，仅在功能完成后才提交会导致过时/冲突吗?
I am in conflicted minds on the rule to commit at the end of the day and when a feature has been added. I say at the end of the day as to ensure the repository is as up to date as possible. However code at the end of the day may be incomplete/break functionality. However committing only when features have been completed can caused out of date/conflicts?
如果您对我的任何想法以及我遗漏的任何想法提出批评，我将不胜感激.
I'd appreciate your critic on any of my ideas and any of your ideas which I have missed out.
谢谢！
推荐答案
更多注意事项:(尽量不重复已经说过的内容..)
Some more notes:(have tried not to repeat what has been already said..)
分支:
除了为上述大量功能开发分支之外，您还可以在需要进行发布后修复工作时进行分支，而并行工作正在主线/主干上进行.
Besides branching for the large chunks of feature development mentioned above, you can branch when you need to work on post-release fixes, while parallel work is progressing on the mainline/trunk.
如果您使用的分支存在时间很长而没有合并到主线开发中，则定期反向合并.这将有助于与主干开发保持同步，并最大限度地减少大爆炸合并的并发症.
Reverse merge regularly if you are using branches that live for long without getting merged to mainline development. This will help to stay in sync with the trunk development and minimize complications of a big bang merge.
注意你命名分支的方式.我们尝试以它所基于的里程碑命名分支.当您需要快速比较或报告时，甚至在浏览某些内容时(如果名称不言自明)，它会很有帮助.
Pay attention to the way you name your branches. We try to name the branches after the milestone it is based off. It helps when you need quick diffs or reports or even while browsing for something, if the names are self explanatory.
由于在 SVN 中分支是一个廉价的副本，我们尝试始终在项目目录的根目录下进行分支(如果它是文件夹主干本身，那么该分支将不在主干上)——这避免了以后的混淆关于谁在何处分支并避免必须运行命令才能找到它.如果您需要从分支结帐东西，那么您可以使用该分支下的所有内容 --- 如果您碰巧需要它.
Since in SVN the branch is a cheap copy, we try to always branch at the root of the project directory (if its the folder trunk itself, then the branch will be off trunk) -- this avoids confusion later about who branched off where and avoids having to run commands to find it out. And if you need to checkout stuff from a branch everythign under the branch is available to you --- if you happen to need it.
提交:
我经常对提交进行投票，并以逻辑块的形式提交，这样您就可以通过一个共同的提交消息来绑定相关文件.这非常适合当您想要一个日志并且报告是分块完成的，并且一堆文件都与相关评论整齐地捆绑在一起.
I vote for commits often and in logical chunks so you can tie the related files by a common commit message. This is great for when you want a log and the reporting is done in chunks with the bunch of files all tied up neatly with relevant comments.
我投票支持频繁提交，即使不是每天.这是一种心态.一旦你看到早期提交的好处(当然在开发人员检查基本编译错误并在他们的开发框中运行单元测试之后)，你会很高兴发现那些早期的错误/构建问题.如果您计划每晚运行构建或使用持续集成工具，最好让人们尽早提交，以帮助深入了解集成的工作流并对其运行测试.
I vote for frequent commits, if not everyday. It is a mindset. Once you see the benefits of having early commits (of course after the developers have checked for basic compilation errors and have run unit tests in their dev box), you'd be happy to catch those early bugs/build issues. If you plan to run nightly builds or use a continuous integration tool , you'd be better off getting the folks to commit as early as they can, to help get an insight into the integrated streams of work and run tests on them.
标签:
- 确定发布命名约定 - 尽管这看起来微不足道，但拥有好的标签名称会有所帮助.还要确保标记的提交注释准确指定了标记此版本存储库的原因.我们仅在进行里程碑构建时进行标记，因此在我们的示例中，我们将标记提交消息与我们用于给定构建的连续构建编号(巡航构建标记)进行映射.它还有助于定义版本编号方案和字段，以便您可以将它们用于标签.
这篇关于Subversion 的标准实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
