We use Perforce in my workplace, and we decided to try using threads to isolate individual development efforts. Some of us have a lot of experience with Git, so we (possibly incorrectly) map Git conventions to threads.
The problem is the function branches / function flows and how to remove them. We already have more than 30 threads, but some of them are outdated and are no longer active.
If we delete a stream, the list of streams becomes a little cleaner, but the depot files remain in any state in which they were left. If someone later creates a new stream with the same name (which is quite plausible in our environment), they will definitely need to merge the latest files from Main down into the stream. Worse, if someone creates a thread, does some search commits, and then discards the thread, the next owner of the thread should be careful to put the thread in good condition first.
We could take another step and delete the depot files associated with the stream before we delete the stream, but then we must be careful not to copy this change to Main. When resurrecting a stream, we can forcefully integrate Main into the stream's stream path, which should create a clear separation between two separate stream modes.
In any case, these are just some of the ideas that I had. I really hoped to see if anyone had any recommendations on using threads as function branches, and in particular if anyone had practical tips on how to resign and maybe later create a thread with the same name to be used for the new function. Or, perhaps, we look at the flows in the wrong way, and we need to find a solution that does not include “function flows” - suggestions on these lines will also be evaluated.
Update
In the end, we decided to just create a new thread for each function. In the stream name, we include the problem number along with the vaguely simple English name for the stream. This allows us to keep the work separate, prevents the "accidental" resurrection of dead threads, and it gives us a clear time to exit the "specification stream" half of the stream (that is, when the problem is closed). We end up with a lot of clutter in the actual depot tree, but I see no way to avoid this. The graphical representation of the stream is controllable if you deselect most threads. After all, this is not a great solution, but it seems to be the best we can do until Perforce adds some even lighter branch.
We have not upgraded the Perforce server to a level that supports task flows. Further research leads me to believe that this will help with some mess, but not with naming problems. It is also not yet clear whether the clutter in the depot tree can hide task flows. I will find out when we update our server.