我们在工作场所使用Perforce，我们决定尝试使用流来隔离单独的开发工作。我们中的一些人对Git有丰富的经验，所以我们（可能不正确）将Git约定映射到流。
手头的问题是功能分支/功能流以及如何淘汰它们。我们已经拥有超过30个流，但其中一些是陈旧的，不再活跃。
如果我们删除一个流，则流列表会变得更清晰一些，但是仓库文件仍处于剩余状态。如果有人后来创建了一个具有相同名称的新流（这在我们的环境中相当合理），他们需要确保将Main中的最新文件合并到流中。更糟糕的是，如果有人创建了一个流，进行了一些探索性的提交，然后放弃了这个流，那么下一个流所有者必须要小心，首先要让流进入良好的状态。
我们可以更进一步，在删除流之前删除与流关联的库文件，但是我们必须小心不要将此更改复制到Main。当重新生成流时，我们可以强制将Main集成到流的depot路径中，这应该在流的两个单独的用法之间创建一个明确的划分。
无论如何，这些只是我的一些想法。我真的希望看看是否有人建议如何使用流作为功能分支，特别是如果有人有任何关于如何退休的实用建议，或者稍后可能创建一个用于新功能的同名流。或者，也许我们正在以错误的方式查看流，我们需要找到一个不涉及“特征流”的解决方案 - 这些方面的建议也将受到赞赏。
更新
最后，我们决定只为每个功能创建一个新流。在流名称中，我们包括问题编号，以及流的模糊英文名称。这允许工作保持完全分离，防止死流“意外地”复活，并且它使我们有一个明确的时间来退出流的“流规范”一半（即当问题关闭时）。我们最终在实际的仓库树中出现了很多混乱，但我认为没有办法避免这种情况。如果取消选择大多数流，则可以管理图形流视图。最后，这不是一个很好的解决方案，但它似乎是我们能做的最好的事情，直到Perforce增加了一些更轻量级的分支。
我们尚未将Perforce服务器升级到支持任务流的服务器。进一步的调查让我相信它会有助于解决一些混乱，但不会有命名问题。目前还不清楚是否可以使用任务流隐藏库中的混乱。我会在升级服务器时找到答案。
答案 0 :(得分：3)
您是否看过Perforce的最新2013.1版本？新的“任务流”功能听起来就像是你正在寻找的东西！
答案 1 :(得分：1)
对于旧版本P4的用户，如果您真正彻底淘汰了一个流，则可以通过p4admin删除其文件。如果您希望保留更改历史记录，请不要这样做。
如果您关心更改历史记录，则不应该删除流。只需通过删除流来让它们休息。您可以“恢复”流（如果您想重新使用该名称）并合并到流中，接受来自父流的所有更改;但是这并不是真的值得推荐的。拥有一个阻止名称重用的命名方案可能要好得多。
注意：如果您在P4V中查看流库，您可以看到仍然在P4中拥有其文件/历史记录的“已删除”流。如果您不想“复活”已删除的流，请务必在创建新流之前检查此列表。
答案 2 :(得分：1)
我们通过进入流的高级选项卡并选中“将文件提交到限制为流所有者的流”来管理这一点，因此实际上除了创建它的CM团队之外，它都被锁定。