Streams: FAQ, Part I
I've had feedback of two kinds since I started this stream blog series. One kind asks for more technical detail, the other asks for less. So, instead of obliging either camp, I am dedicating this week's post to answering FAQs. And, in anticipation of even more questions, let's just call this Part I.
When will streams be available?
The plan is to introduce the streams feature in the 2011.1 release. Currently it's looking like 2011.1 will be ready for beta in September. The GA is scheduled for November. Assuming the beta goes well, you'll see the streams feature in the GA. (And don't hold us to this -- schedules can change!)
What will performance be like?
"At least as good as p4 integ," is what I used to say when I worked with the design team on this project. But our engineers have really overshot the mark. Their focus on performance has made streams more efficient than classic codelines for most uses.
Here's an example: The Perforce Server has always been smart about storing a history of integration data. ("Integration" being branching, copying, and merging.) Now, using streams as a frame of reference, the server caches pending integration data as well. When you query to find out what needs to be integrated between a stream and its parent, the server response time varies from "pretty darn quick" to "right away".
Will streams support private branching?
Another feature Perforce is working on, completely outside of streams, is local private branching. Alan Teague and Zig Zichterman will be introducing this feature at the Perforce User Conference.
Meanwhile, as a little eating-our-own-dogfood project, we've set up a Perforce server with triggers that give owners complete control over access to their own streams. In addition to flushing out a covey of alpha bugs, this project is proving that streams are a great framework for access control. If what you want is private branching in the server, streams, plus triggers and protections are a nice solution.
Can you do branching in place with streams?
Yes. "Branching in place" is the ability to branch files and switch your workspace between branches without actually touching your local files. It's an extremely efficient operation when switching between branches whose files are largely identical.
A very satisfying by-product of the engineering that went into streams and local private branching is that p4 client (alias p4 workspace) and p4 sync now have behaviors that support branching in place. These behaviors are available with or without streams.
Are streams lightweight branches?
A stream can be a very lightweight branch if you use its view to limit the branch-able components of the parent stream; the rest of the parent stream is simply mirrored in the child stream's workspaces. I'm going to devote an upcoming blog post to this topic. It's tricky, it's Perforce-y, and it's very, very nice.
Otherwise, branching stream files is just like branching classic Perforce files. The server doesn't actually copy the files themselves. Instead, it makes "lazy copies" -- database pointers to branched files. This is not as lightweight as in systems where a branch is a single database pointer, and it can be a problem if you're branching huge file trees very frequently. Stream views are designed to nip this problem in the bud.
That being said, our server developers have been tossing around an idea for using the stream as a container for bona fide lightweight branching. This is but a gleam in their eyes at the moment; we'll see what happens with it.
How do streams enforce good behavior?
Streams give users a roadmap of where and how to do branching and merging. They guide good behavior rather than enforce it. Some commands, like p4 copy and the new p4 merge, can enforce the intended flow of change between streams. The classic p4 integ command can be used to "go against the flow", however. The only thing a non-privileged stream owner can do about that is to configure the stream to reject other users' changes. For industrial-strength enforcement, triggers and protections will do the job.
I hope these answers will suffice for the time being. Some of what I'm writing about is still being tweaked, and I don't have the exact answers yet. And if you're in the camp that finds this too technical or too detailed, forgive me. Some great engineering is coming to fruition here, and I hate to leave anything out.
More next week. Keep those cards and letters coming.