我们在工作中使用Perforce，并且我们决定尝试使用streams来隔离不同的开发任务。我们中的一些人有Git的丰富经验，因此我们（可能不正确地）将Git惯例映射到streams上。
问题在于特性分支/特性stream以及如何废弃它们。我们已经有超过30个streams，但其中一些已经过时并且不再活跃。
如果我们删除一个stream，则stream列表会变得更干净，但存储库文件仍保持它们被遗留的状态。如果稍后有人使用相同的名称创建新的stream（在我们的环境中非常有可能），他们需要确保将最新的文件从Main合并到stream。更糟糕的是，如果有人创建了一个stream，进行了一些探索性提交，然后放弃了stream，那么下一个stream所有者必须小心地先将stream设置为良好的状态。
我们可以更进一步地删除与stream相关联的存储库文件，然后再删除stream，但是我们必须小心不要将此更改复制到Main。当重新启用stream时，我们可以将Main强制集成到stream的存储库路径中，这应该在两个独立的流使用之间创建一个清晰的分割。
总之，以上只是我提出的一些想法。我真的希望看看是否有人推荐如何将streams用作特性分支，特别是是否有任何实际建议可以废弃并稍后创建一个具有相同名称的stream以用于新功能。或者，也许我们正在错误地看待streams，并且我们需要找到一种不涉及“特性stream”的解决方案——在这方面的建议也将受到赞赏。
更新
最终，我们决定为每个特性创建一个新的stream。在流名称中，我们包括问题编号以及模糊的平易近人的流名称。这样可以完全保持工作的分离，防止“意外”复活无效的stream，并且它给我们清晰的时间来停止使用stream spec部分（即当问题关闭时）的stream。我们最终会在实际的存储库树中得到大量杂乱无序的内容，但我没有发现任何避免这种情况的方法。如果您取消选择大多数streams，则图形stream视图是可管理的。总之，这不是一个很好的解决方案，但在Perforce添加了更轻量级的分支之前，它似乎是我们能做的最好的事情。
我们尚未升级Perforce服务器以支持任务流。进一步调查表明，这将有助于解决一些混乱问题，但不能解决命名问题。还不清楚是否可以使用任务流隐藏存储库树中的混乱。我们升级服务器时会找出答案。
问题在于特性分支/特性stream以及如何废弃它们。我们已经有超过30个streams，但其中一些已经过时并且不再活跃。
如果我们删除一个stream，则stream列表会变得更干净，但存储库文件仍保持它们被遗留的状态。如果稍后有人使用相同的名称创建新的stream（在我们的环境中非常有可能），他们需要确保将最新的文件从Main合并到stream。更糟糕的是，如果有人创建了一个stream，进行了一些探索性提交，然后放弃了stream，那么下一个stream所有者必须小心地先将stream设置为良好的状态。
我们可以更进一步地删除与stream相关联的存储库文件，然后再删除stream，但是我们必须小心不要将此更改复制到Main。当重新启用stream时，我们可以将Main强制集成到stream的存储库路径中，这应该在两个独立的流使用之间创建一个清晰的分割。
总之，以上只是我提出的一些想法。我真的希望看看是否有人推荐如何将streams用作特性分支，特别是是否有任何实际建议可以废弃并稍后创建一个具有相同名称的stream以用于新功能。或者，也许我们正在错误地看待streams，并且我们需要找到一种不涉及“特性stream”的解决方案——在这方面的建议也将受到赞赏。
更新
最终，我们决定为每个特性创建一个新的stream。在流名称中，我们包括问题编号以及模糊的平易近人的流名称。这样可以完全保持工作的分离，防止“意外”复活无效的stream，并且它给我们清晰的时间来停止使用stream spec部分（即当问题关闭时）的stream。我们最终会在实际的存储库树中得到大量杂乱无序的内容，但我没有发现任何避免这种情况的方法。如果您取消选择大多数streams，则图形stream视图是可管理的。总之，这不是一个很好的解决方案，但在Perforce添加了更轻量级的分支之前，它似乎是我们能做的最好的事情。
我们尚未升级Perforce服务器以支持任务流。进一步调查表明，这将有助于解决一些混乱问题，但不能解决命名问题。还不清楚是否可以使用任务流隐藏存储库树中的混乱。我们升级服务器时会找出答案。