Category: Streams

Perforce streams let you capture important information about what actually goes into a codeline. Using stream paths, you can select active modules (modules that are branched and worked on), import other modules as read-only dependencies from the parent stream, and so on. (For more information on stream paths, read this post by Laura Wingerd.)

Of course, the stream paths may change over time. Let's say that originally you were importing version 1.0 of an external library, so you had a statement like this in your stream definition:

    import acme/... //depot/acme-lib/rel/1.0/...

At some point there's a 1.1 patch for this library that you want to work with, so you pull in that new version instead.

    import acme/... //depot/acme-lib/rel/1.1/...

Now let's think about how to reproduce the state of this codeline in the future. Maybe I shipped an important milestone as of changelist 100, and at that time I was using the 1.0 version of acme-lib. If I create a workspace for this stream and run p4 sync @100, I won't...

This is the second in a three-part series on virtual streams.

One of the first things you learn when you graduate to a world-class version management tool is to love branching. That's a tough transition if you came from a tool that did branching poorly, but there are no poisoned apples in Perforce's tree of branching wisdom. There is a small worm in one of those apples, however, and we've now got a better way to deal with it.

Let's say that I manage a team where each developer uses her own task branch. My team is working on a set of new features for an upcoming release code-named Thunder.

But now the product manager tells me that she's shuffling the priorities, and my team's work is now targeted for the Lightning release. Uh oh – I'd have to reparent all of the task branches used by my team.

A better model is to use a very lightweight container stream for my team.

Now I can move all...

Perforce Release 2012.1 introduces the virtual stream, a powerful abstraction of the stream feature. A virtual stream isn't actually a stream at all -- it is simply a filtered view of its parent stream. Creating and using a virtual stream, however, is the same as creating and using a real stream. I'll demonstrate some of that here, building on the stream view explanation I gave in an earlier blog.

Virtual Streams as View Filters

Let's say you're working at Ace Engineering, where there's an active development branch defined thus:

Stream:  //Ace/dev
Parent: //Ace/main
Type:   development
Paths:
    share ...

//Ace/dev is a depot path, and it contains files. You can work with these files by switching your client workspace to the //Ace/dev stream. But what if the //Ace/dev path is huge? And what if you have a team of developers who work with only a small subset of these files? Yes, you could branch a smaller child stream from //Ace/dev. But now, with virtual streams, you don't need to. You can create a virtual child stream that simply narrows the //Ace/dev stream's view. For example:

...