我们在工作场所使用Perforce，我们决定尝试使用流来分离单独的开发工作。我们中的一些人在Git方面拥有丰富的经验，因此我们（可能是错误地）将Git约定映射到流。
当前的问题是要素分支/要素流以及如何停用它们。我们已经有30多个流，但是其中一些是过时的，不再活跃。
如果我们删除流，则流列表将变得更整洁，但是软件仓库文件将保持任何状态。如果以后有人创建一个具有相同名称的新流（在我们的环境中这很合理），那么他们将需要确保将Main中的最新文件合并到该流中。更糟糕的是，如果有人创建了一个流，进行了一些探索性的提交，然后放弃了该流，那么下一个流所有者将必须谨慎，首先要使流进入良好状态。
我们可以更进一步，并在删除流之前删除与该流关联的软件仓库文件，但是随后我们必须小心，不要将此更改复制到Main中。当恢复流时，我们可以强制将Main集成到流的软件仓库路径中，这应在流的两种不同用法之间建立清晰的划分。
无论如何，这些只是我的一些想法。我真的很希望看到有人对如何使用流作为功能分支提出建议，特别是是否有人对如何退休以及以后创建一个名称相同的流以用于新功能有任何实用建议。或者，也许我们正在以错误的方式看待流，并且我们需要找到一种不涉及“功能流”的解决方案-沿着这些思路提出的建议也将不胜感激。
更新资料
最后，我们决定只为每个功能创建一个新的流。在流名称中，我们包括问题编号，以及流的英文名称。这样可以使工作完全分开，防止死流“意外”复活，并且为我们提供了明确的时间来淘汰流的“流规范”的一半（即，当问题解决时）。我们最终在实际的仓库树中造成了很多混乱，但是我看不出有什么方法可以避免这种情况。如果取消选择大多数流，则图形流视图是可管理的。最后，这不是一个很好的解决方案，但在Perforce添加一些甚至更轻量级的分支之前，这似乎是我们可以做的最好的选择。
我们尚未将Perforce服务器升级到支持任务流的服务器。进一步的调查使我相信，这将有助于解决一些混乱情况，但不能解决命名问题。还不清楚是否可以用任务流隐藏软件仓库树中的混乱情况。我将在升级服务器时查明。
最佳答案
您是否查看过Perforce的最新2013.1版本？听起来新的“任务流”功能正是您所需要的！