我以前使用过 SVN 的基本功能来签入和签出代码。我从未接触过分支和更复杂的东西。是否可以使用 SVN 来保留源代码文件的主版本，为不同的项目制作略有不同的版本，然后将对主版本的任何更改复制到其他版本而不覆盖对其他版本所做的更改？
我有点怀疑这是否可以轻松处理而无需手动处理冲突，所以让我问另一个问题：如果我用一种通用代码库创建了一个存储库，然后使用类继承在单独的文件中对其进行了任何项目特定的更改，是否可以将其设置为在同一个文件夹中检出两个存储库？
答案1
在 SVN 中，这是一件很难的事情。它需要大量的手动合并，而且很容易出错。但是，如果你有选择，比如@Ash 提到分布式版本控制系统可以很好地处理这种情况。特别是，我知道 Git 使这变得非常容易。
这git-rebase命令完全符合您的要求。假设您有一个源文件的主分支或“原始”分支，您只需创建一个新分支（“mywork”）即可进行项目特定的更改（由块 C6 表示）。
现在，随着代码主分支的不断变化（修订版 C3 和 C4），您只需将项目特定分支重新定位到新的修订版，您将获得在项目分支的主分支上所做的所有更改。
仍有可能需要手动合并，但可能性要低得多。Git 可以减轻执行合并操作的很多麻烦。查看Git Book 的 rebasing 章节了解更多信息。
答案2
我认为使用 subversion（至少是当前版本）来解决这个问题非常困难，甚至不可能，但分布式版本控制系统可以处理它。我使用 Mercurial 解决了这个问题：
在“服务器”端：
- 创建一个“主”存储库
- 克隆该存储库以创建存储库的项目特定版本（克隆是在其他地方复制整个存储库）
在“客户端”方面：
- 将项目存储库克隆到你的开发区域并检查
- 进行更改，在本地进行大量提交，并根据需要推送回服务器
如果主库发生更改，这些更改可以“拉”到项目特定的存储库中，然后流到本地存储库。如果对项目特定存储库所做的更改被认为适合“主库”，则可以将它们推回到主库。Mercurial 会记住父存储库之间的路径，因此所有内容都可以组合在一起。分支（您倾向于更多地使用）和存储库之间的合并通常很轻松。一个缺点是 Mercurial 不允许“挑选”更新，但这可以成为一种优势，因为它可以让您避免将来合并时出现的潜在麻烦。
完成所有这些工作可能需要更大的学习曲线，但可能值得研究。
答案3
简短的回答是“不”。您描述的问题是在发生更改时合并分支。有助于但最终你合并了两个都发生了变化的代码分支。这种情况可能会导致冲突，需要人工干预。
答案4
这个问题在 SO 上问不是更好吗（SO 上有超过 5,000 个 SVN 问题）？我看到这里有一些 SVN 问题，但我不知道什么更适合这两个网站。