我想知道使用Subversion的标准做法是否需要考虑其他因素。
我有几个是:
/tags/trunk和/branches的目录结构所有工作都在主干中完成，不会破坏功能在进行了重大结构更改或添加了破坏核心功能的功能时(视情况而定)，分支标签包含稳定的发行版在开始工作之前始终执行更新在一天结束时/已添加功能时提交更改提交笔记包含相关描述基于功能的提交-不要掩盖
我对在一天结束时和添加功能后提交的规则存有矛盾。最后，我要确保存储库是最新的。但是，一天结束时代码可能是不完整/中断功能。但是，仅在功能完成后才提交会导致过时/冲突吗？
感谢您对我的任何想法以及我错过的任何想法的批评。
谢谢! 还有一些注意事项:(尝试不重复已经说过的话。)
分行:
除了为上面提到的大部分功能开发分支之外，您还可以在需要处理发布后修订时进行分支，而同时在主线/主干上正在进行并行工作。 如果您使用的分支生命周期很长而没有被合并到主线开发中，则定期进行反向合并。这将有助于与躯干发展保持同步，并最大程度地减少大爆炸合并的复杂性。 注意您命名分支的方式。我们尝试根据其建立的里程碑来命名分支。如果您的名字很容易理解，那么当您需要快速比较或报告时，甚至在浏览某些内容时，它都可以提供帮助。 因为在SVN中分支是便宜的副本，所以我们尝试始终在项目目录的根目录分支(如果它本身是文件夹主干，则分支将不在主干)–这样可以避免以后有人混淆谁分支的地方并避免必须运行命令来查找它。而且，如果您需要从分支机构 checkout 东西，那么分支机构下的每个人都可以使用---如果您碰巧需要它的话。
提交:
我经常以逻辑块的形式对提交进行投票，因此您可以通过一条常见的提交消息将相关文件绑定(bind)在一起。当您想要一个日志并且报表以大块的形式完成时，这堆文件与相关注释整齐地捆绑在一起时，这非常有用。 我(如果不是每天)投票支持频繁提交。这是一种心态。一旦您发现了尽早提交的好处(当然，在开发人员检查了基本的编译错误并在其开发框中运行了单元测试之后)，您将很高兴发现这些早期的bug/构建问题。如果您打算运行夜间构建或使用持续集成工具，最好让人们尽早执行，以帮助您深入了解集成的工作流并对其进行测试。
标签:
禁止发布命名约定-尽管这看起来很琐碎，但有助于使用良好的标记名。还要确保标签的提交注释准确指定了为什么要标记此版本的存储库。我们仅在进行里程碑构建时才进行标记，因此在我们的情况下，我们将标记提交消息与给定构建所使用的连续内部版本号(cruise build标签)进行映射。定义发布编号方案和字段也很有帮助，因此您可以将其用于标签。