我喜欢建立svn结构和策略的建议。这是合约。
我有一个大型计划，我想分成两个独立的程序，每个程序将进一步独立开发。这两个独立的程序将连续运行，通过文件进行通信，并且与现有的单个程序完成相同的工作，但分为两个阶段。
当这一切都完成后，两个程序（以及连续运行它们的命令文件）将成为产品，原始单个程序将退回牧场，但如果有问题仍可供咨询。
现在只有一个程序员（moi）和一个只运行它的客户。总会有一个客户。最终，不同的程序员将在这两个部分上工作，尽管最初它只是我的两个部分。这种不同程序员独立工作的能力是分裂的主要原因，因此对我来说不是问题。
我的暂定开发策略是将单个程序克隆两次，然后将每个克隆变为两个独立部分中的一个。这两部分将共享一些代码，结构和常量，但并不多。我可能还需要一个单独的小代码库用于命令文件。
人们推荐的svn结构和策略是什么？我应该在原始代码或两个单独的代码库中创建两个分支或标记吗？我应该如何构建回购？等吗
假设现有的单个程序还没有在svn中（它是，但不是很优雅，所以我很乐意重新开始）。
我几乎是一个天真的人，并希望尽可能简单（但并不简单 - 感谢Albert）。现在我有时通过Tortoise使用svn，有时使用JetBrains RubyMine。我不确定这两者是否能够很好地协同工作，所以我愿意采用这种方式。我在我的网络托管服务上创建了svn repos，我很高兴，所以我真的不想改用git。
（我查看了相关问题，似乎没有一个问题适合我的情况。）
答案 0 :(得分：2)
trunk/
project1
project2
etc
我认为你在想这个:)特别是如果程序在通信和接口方面非常相关。您可能希望在进行影响双方的更改时保持同步。您仍然可以单独标记项目目录，同时分支两者同时进行重大更改。
你有可能最终得到一个project3（或常见的东西），所以最好让它们保持密切，不要将它们放在不同的存储库中。
答案 1 :(得分：1)
我喜欢采用相同原始代码库并将其放入两个项目的初始计划。为supervisor脚本添加第三个。如果确实存在共享代码，请将其放在团队可以访问的一个地方中。这可能是第四个项目，或者只是让你的团队知道共享代码进入项目y。您的构建工具可以负责从正确的项目中提取共享部分，但请不要在多个位置维护它的副本。
BTW：这听起来像是一个转换为git的好机会。通过使用feature branch或git flow类型的工作流程，您应该能够更轻松地扩展开发人员数量。＆lt; - 但我仍然相信这一点。
答案 2 :(得分：1)
我会在一个存储库中创建多个项目。布局如下所示：
/
project1/
trunk/
project 1 files and folders
tags/
branches/
project2/
trunk/
project 2 files and folders
tags/
branches/
project3/
trunk/
project 3 files and folders
tags/
branches/
我喜欢你减少启动代码库以创建两个项目的想法。我首先将它全部提交给一个项目，然后使用svn copy获取第二个项目中的基线代码，并在每个项目中独立地进行。