我们目前正在处理Web应用程序的多个分支。选择的VCS是SVN。
我们有：
v1：/ trunk，实时应用，错误修正
v2：/ branches / 1，附加功能，没有主干错误修正
计划了更多步骤。当前的计划是使用稳定的客户端接受v1，然后将v2合并到v1中。那时肯定会弹出v3。
问题是客户端需要更多透明度，他目前只能看到并测试v1。如果我也让v2可用，那么他们很可能无法分辨版本并再次报告v1（固定）错误。这将是一个烂摊子，imo。 我也不喜欢每天合并的想法，因为将新旧错误分开会更难。
我觉得这对我们的开发过程来说比技术问题更严重。我们欢迎任何解决问题或使双方对未来发展更加便利的灵感。感谢。
修改
一个部分问题也是我的同事对版本控制不太深入，使用2个分支对他们来说已经不方便了。但是，如果我找到更好的策略，我可能会强迫他们做正确的事。
EDIT2
谢谢大家的答案。经过一番思考后发现整个问题更大，因为我们在SVN中保留了二进制文件。如果没有非常严格的政策，合并将是不可能的，并且可能会被削弱。
答案 0 :(得分：0)
似乎有点无组织。将版本2合并到版本1？嗯？你剩下什么版本？版本1还是？具有版本2的功能？什..？
我喜欢小项目：
Trunk：当开发人员确信它正在运行时，这就是事情的发生地。在主干上进行内部QA测试。
标签：通过从主干复制为每个版本创建一个新标签。将您的标签命名为“/tags/v1.0”或“/tags/v1.1”，或者您想要这样做。如果您需要外部客户端来测试某些内容，请将您的标记命名为“/tags/v1.0-beta”，然后给它们进行测试。不要让他们用行李箱进行测试，因为他们在测试时你仍然会继续开发！
分支：当你有一个需要一些时间来开发的功能时，你不能在它完成之前将它提交到主干。做一个分支。在您正在实现的功能之后命名，例如“/ branches / user_logins”。
错误修正被提交到主干并包含在下一个标记版本中。如果有一个必须在今天发布的紧急错误修复，但是主干中还有尚未发布的东西，请制作另一个标签但是从错误发布的标签而不是从主干中复制，称之为“v1”。 0.1“，修复那里的bug，给他们一个新版本，然后将该bugfix合并到trunk中。
答案 1 :(得分：0)
该死的。您的开发过程无法确认V1中的故障。如果你没有将V1中的修正结转到V2，你怎么能希望V2比V1更好？！
错误修复始终比新功能更重要。如果旧功能被破坏而且不值得修复，那么将其删除。
摆脱懒惰的屁股;如果您或某人已经努力修复V1中的缺陷，请确保它不再出现在V2中。修理它！如果您的代码非常垃圾，以至于每天都会出现这种情况，那么请停止使用V2，并专注于将错误修复降低到较低的频率。如果你无法使V1功能正常工作，那么你永远不会进入V3。
我也可能建议使用“mercurial”或“git”或“bazaar”而不是svn。如果您发现并使用“cherrypicking”和“排队”功能，他们在保持管理类型方面要好得多：您可以添加一项功能并将“管理 - 思考 - 将 - 保存 - 生产”投入到生产中没有拉出他们提出的所有其他半生不熟的想法然后放弃了。如果政治阻止转向分布式版本控制，只需自己使用它，只将你提供的东西（以及他们想要的东西）推送到svn。
答案 2 :(得分：0)
对我而言，似乎你切换了分支和主干这两个术语。通常，trunk是活动的开发分支，其中的版本存在于自己的bugfix分支上。它看起来你使用trunk作为release1 bugfix分支，而/ branches / 1是真正的开发中继，并且因为你不能为release2创建第二个trunk而被卡住。
如果我是对的，我建议将当前的主干移动到/ branches / v2分支，将/ branches / 1分支移动到/ trunk。在这种情况下，您可以根据需要拥有尽可能多的发布分支（但尽量保持尽可能低），而主要开发线位于/ trunk。
有关详细信息，请参阅http://nvie.com/posts/a-successful-git-branching-model/。虽然它适用于git，但有很多与VCS无关的信息。
答案 3 :(得分：0)
我同意你的其他海报。 c0rnh0li0你需要重新考虑你的签到和合并政策。
查看您的存储库布局，并尝试定义团队中任何人都可以轻松重复的规则，这些规则有助于填充从稳定到不稳定的更改。对我来说，这允许合并主要在一个方向。
维护分支方案的示例布局
branches/v1
-approved and shipped/deploy
-Only bugfixes allowed
branches/v2
-is not approved by the client but nearly ready
-Fixes and feature-commits allowed that focus on getting v2 stable & ready
-receive bugfixes commited in v1 (merge down)
branches/v3
-is not approved by the client and far from ready
-Fixes and feature-commits allowed that focus on getting v3 stable & ready
-receive bugfixes commited in v2 (merge down)
trunk
-All syntax-error free commits allowed (mainline)
-receive merges from LATEST stable branch (merge down from v3 in this case)
顶级分支是最古老的，具有最少的功能但是稳定性最高（经过良好测试，最近没有添加许多功能）。另一方面，行李箱非常不稳定，并且具有前沿功能。 v2和v3之间是Somewhet。 您还可以在行李箱“下方”添加一些比行李箱更不稳定的特征分支。合并方向保持不变。我想引用咒语“合并，复制”。
您准备/维护的并发版本越多，您必须执行的合并越多。但是由于合并跟踪它并不是一个任务恕我直言，它确保没有留下错误修复，必须再次手动重新发现和修复。
我在这里没有提到标签。如果您可以创建它们并且不直接从分支中释放。
现在虽然这应该能够很好地修复您的变更流程管理，并帮助将高风险开发与低风险隔离开来，但仍然存在向客户端可视化他正在测试/预览的问题。
将应用程序VCS源可视化到客户端
的可能性：