What is a good way to retire a Perforce stream
branch, perforce
Solution
Have you looked at the latest 2013.1 release of Perforce? The new "Task Streams" feature sounds like it's just what you're looking for!
Problem
We use Perforce at my workplace, and we have decided to try using streams to isolate separate development efforts. A few of us have extensive experience with Git, and so we're (possibly incorrectly) mapping Git conventions to streams. The issue at hand is feature branches / feature streams and how to retire them. We already have over 30 streams, but some of them are stale and no longer active. If we delete a stream, the stream list gets a bit cleaner, but the depot files remain in whatever state they were left. If somebody later creates a new stream with the same name (which is fairly plausible in our environment), they will need to be sure to merge the latest files from Main down to the stream. Even worse, if somebody creates a stream, makes some exploratory commits, and then abandons the stream, the next stream owner has to be careful to first put the stream into a good state. We could go a step further and delete the depot files associated with a stream just before we delete the stream, but then we have to be careful to not copy this change up to Main. When resurrecting the stream, we could force integrate Main into the stream's depot path, which should create a clear division between the two separate usages of the stream. In any case, those are just some ideas I had. I was really hoping to see if anybody has recommendations for how to use streams as feature branches, and in particular if anybody has any practical advice for how to retire and perhaps later create an identically named stream to be used for a new feature. Or, perhaps we're looking at streams the wrong way, and we need to find a solution that doesn't involve "feature streams" - suggestions along those lines would also be appreciated. Update In the end, we decided to simply create a new stream per feature. In the stream name, we include the issue number, along with a vaguely plain-English name for the stream. This allows work to be kept completely separate, prevents dead streams from "accidentally" getting resurrected, and it gives us a clear time to retire the "stream spec" half of a stream (i.e. when the issue is closed). We end up with a lot of clutter in the actual depot tree, but I don't see any way to avoid that. The graphical stream view is manageable if you deselect most of the streams. In the end, not a great solution, but it seems to be the best we can do until Perforce adds some even lighter-weight branch. We haven't yet upgraded the Perforce server to one that supports task streams. Further investigation leads me to believe that it will help with some of the clutter, but not with the naming issues. It's also not yet clear if the clutter in the depot tree can be hidden with task streams. I'll find out when we upgrade our server.