我们在我的工作场所使用 Perforce，我们决定尝试使用流来隔离单独的开发工作。我们中的一些人在 Git 方面拥有丰富的经验，因此我们（可能不正确地）将 Git 约定映射到流。
手头的问题是功能分支/功能流以及如何淘汰它们。我们已经有 30 多个流，但其中一些流已经过时并且不再活跃。
如果我们删除一个流，流列表会变得更干净一些，但仓库文件仍然保持在它们留下的任何状态。如果后来有人创建了一个同名的新流（这在我们的环境中是相当合理的），他们需要确保将 Main 中的最新文件合并到流中。更糟糕的是，如果有人创建了一个流，进行了一些探索性提交，然后放弃了该流，那么下一个流所有者必须小心地首先将流置于良好状态。
我们可以更进一步，在删除流之前删除与流关联的 depot 文件，但是我们必须小心不要将此更改复制到 Main。在恢复流时，我们可以强制将 Main 集成到流的 depot 路径中，这应该在流的两种不同用途之间建立清晰的划分。
无论如何，这些只是我的一些想法。我真的很希望看看是否有人对如何将流用作功能分支有建议，特别是是否有人对如何退休并可能稍后创建同名流以用于新功能有任何实用建议。或者，也许我们正在以错误的方式看待流，我们需要找到一个不涉及“特征流”的解决方案——这些建议也将受到赞赏。
更新
最后，我们决定简单地为每个功能创建一个新流。在流名称中，我们包含问题编号以及流的含糊的纯英文名称。这允许工作完全分开，防止死流“意外”复活，并且给我们一个明确的时间来退出流的“流规范”一半（即当问题关闭时）。我们最终在实际的仓库树中出现了很多混乱，但我看不出有任何方法可以避免这种情况。如果取消选择大多数流，图形流视图是可管理的。最后，这不是一个很好的解决方案，但它似乎是我们能做的最好的，直到 Perforce 添加一些更轻量级的分支。
我们还没有将 Perforce 服务器升级到支持任务流的服务器。进一步的调查使我相信这将有助于解决一些混乱问题，但不会解决命名问题。目前还不清楚仓库树中的杂乱是否可以用任务流隐藏。当我们升级我们的服务器时，我会发现。