我刚刚开始将“Subversion”与“Tortoise SVN 客户端”一起用于我在“Google 代码”上托管的开源项目之一。我想获得一些使用它的最佳实践。我遵循默认文件夹结构（主干、分支、标签）。以下是问题
任何帮助将不胜感激。
【问题讨论】：
标签： svn open-source repository directory-structure
我建议您在开始对文件进行大量修改之前检查文件 (check in early, check in often)。
这取决于，有些人喜欢拥有主干稳定，在分支中工作，然后在功能准备好时将分支合并回主干，但你也可以直接提交后备箱。
这还取决于您将如何工作以及您喜欢在主干中拥有什么（最新的稳定版本或最新的前沿版本）。
【讨论】：
我建议尽早并经常检查。
有很多方法可以做到这一点，但我成功使用过的最常见的方法是在开发分支上工作并在达到稳定点（次要版本发布、里程碑等）时合并到主干。
如果您还没有，请查看red book，这是获取 svn 信息的绝佳资源。
【讨论】：
当我从头开始创建一个新项目时，我通常在 SVN 的用户区域中这样做，例如
/svn/users/me/project1
这是因为大多数项目都是从丢弃原型开始的，而我很少使用分支。一旦一个项目正式发布并接近它的第一个“原型”版本，我会将它迁移到它自己的存储库
/svn/project1/trunk
使用分支需要一些额外的工作，所以除非必要，否则我们不会使用它们。当多个人在同一个项目上工作并且经常发生冲突或者我正在开发一个我可能决定恢复并丢弃的功能时。如果在分支中完成，我可以简单地选择不合并并删除它。
【讨论】：
所有答案都建议您早点入住，经常入住，我完全同意。所以这就是我要说的。但是，我将摘要阅读为：Subversion 适合哪些用途？所以这里有一个答案。
我读过一些公司使用 Subversion 作为他们的应用程序存储库。因此，他们告诉服务器他们要安装应用程序 Y 的版本 X。然后服务器在 SVN 服务器上运行更新。他们还在那里存储了配置文件。然后对配置所做的任何更改（通过最终客户的单独 Web 界面）提交到 SVN 配置存储库。这太棒了。 '当然这些人在 Win2k3 上使用 MS Power Shell，但该技术仍然可以应用到其他地方。
【讨论】：
立即入住，不要提早入住。即使您只需要提交一个包含头脑风暴和一些极其神秘的伪代码的临时文本文件，也请提交。
我（和许多人一样）在进行某种代码搜索或搜索符合我要求的程序时，会找到与您类似的项目。我会阅读您的首页，然后立即浏览您的 SVN 中继，看看您在做什么。
如果你的后备箱里有零代码，我可能会忘记你。如果您至少有一些文件解释了您的预期设计和一些伪代码，我可能会开始向您发送显示我想法的补丁。
一个有空存储库的项目尖叫“永远不会被划伤的痒”......所以尽快推送一些东西。
之后，经常提交。我喜欢做出许多小而有序的承诺，以便轻松跟踪回归和回滚/修复有害修订。
【讨论】：
在创建空白基线项目/解决方案结构后签入。空白，因为在这种状态下它实际上是可编译，尽管没有工作代码。原则是在整个开发过程中保持整个项目 - 至少 - 处于可编译状态，因为团队增量并定期提交小的更改，这样构建几乎不会被破坏。
没有法律要求初次签到必须在干线或分行进行。您可以使用空项目启动 Trunk，使其从一开始就稳定，然后分支进行开发并在完成后将其合并回 Trunk。您还可以选择将空项目签入到分支并开发第一个工作或基本功能，然后再将实质性内容合并到主干中。无论哪种方式，基于第 1 点，Trunk 应该是稳定的并且高质量。仅将高质量内容合并到主干中。
同样，对此类做法没有严格的规定。一些团队将所有内容都分支出来，甚至对变量名称更改进行简单重构。有些团队甚至不知道分支/合并并在单个分支（主干）中开发所有内容。每个团队在这个问题上都有自己的平衡水平。我个人的指导方针是，如果有新功能或重大错误修复或重新设计，请将其分支出来进行测试。如果它是一个小的修复，如字符串拼写错误或在网页中显示四个小数位而不是两个小数位，则修复 Trunk 副本就足够了。当然，“主要”与“次要”的解释会有所不同，因此开发/团队领导应该建立他们的标准。无论哪种方式，都必须有单元/集成测试伴随更改，以验证分支或主干是否按预期工作，尽可能无缺陷。要记住的关键字始终是“高质量、经过测试的代码”。
【讨论】：