Suggested stock photo: http://www.istockphoto.com/photo/businesswoman-searching-files-13879377 Title: 2015.2 Streams Enhancements, Part Two The largest change to streams in the 2015.2 release is the ability to open and submit them similarly to how you can open and submit files: #1211694 (Bug #77627) ** Stream specifications may now be opened and submitted, enabling them to be staged on a particular client and tested before being submitted atomically in a changelist along with a set of files. See 'p4 help streamcmds' for more information. Three new "p4 stream" subcommands have been added to manage this new concept of an open stream spec: p4 stream edit p4 stream resolve [-a<flag>] [-n] [-o] p4 stream revert Just as you can only open a file if it's mapped in your current client, you can only open a stream spec when you are using a client of that stream. The "p4 stream edit" command opens the current stream, creating an open spec that is a copy of the latest submitted spec (its head revision, if you like). When the spec is opened, only some fields are affected; these fields are marked in the spec with an "# open" comment on the relevant lines. Any changes you make to those fields are visible to your client alone; similarly, changes made by other clients to those fields against the submitted version of the spec are not reflected in your open copy. The "p4 stream resolve" command pulls other clients' submitted stream spec changes into your open stream spec. In general "p4 stream resolve" works much like "p4 resolve"; one difference of note is that "p4 stream resolve -af" handles conflicts by appending the conflicting blocks to each other (there are no conflict markers, so be careful). The "p4 stream revert" command abandons your open changes and returns you to the submitted version of the stream spec. Changes that you've made to your open stream spec are made available to other users via the existing "p4 submit" and "p4 shelve" commands. By default, if you have an open stream spec, it is attached to any shelve or submit operation -- unlike a file, the open stream spec is not associated with a particular pending changelist prior to submit or shelve, because the stream spec potentially affects files across multiple pending changelists. To exclude the stream spec from one of these operations, use the new "-Af" flag to specify that only files should be acted upon. So what's the point of this whole concept of an open stream spec? One benefit is that like making a tricky change to a file, you can test a stream spec change and not have it break someone else. Suppose you need to change which branch of external library you "import", and you're not sure if it'll build right with the code in your stream. Rather than running "p4 stream", making the change, and finding out you've just broken the build for everyone, now you can do "p4 stream edit" before running "p4 stream", and test your change before it affects anyone else. Continuing that same example, suppose that the new library does break your build, and to fix it you need to modify some of the files in your stream. If someone else syncs the new versions of the files before the stream is updated, the build breaks; if someone else gets the updated stream before you submit the new versions of the files, the build also breaks. But by opening the stream, opening the files, making all your changes, and submitting them all in one changelist, you prevent anyone else from ever seeing a "broken" state -- everyone else syncs the updated files right along with the updated stream-generated view. Note that for now, if you never run the new "p4 stream edit" command, none of this will affect you in the slightest (with one exception: if someone else opens their stream spec and then shelves it, you'll get their version of the stream spec opened in your workspace when you unshelve that changelist). You are still able to edit a stream directly with the "p4 stream" command, and in that case you will still see the old behavior of having that update be instantly available to everyone else. We're planning to do even more with streams in upcoming releases, so keep watching this space!
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#1 | 30197 | Sam Stafford | Rename a lot of feature-specific entries to include the release. | ||
//guest/sam_stafford/doc/p4blog/stream-open.txt | |||||
#1 | 30196 | Sam Stafford |
Old blog entries. Most of these can be found elsewhere, like on archive.org or sometimes partially copy+pasted into KB articles without their original formatting, but since all the original blog navigation pages are gone (and don't really work very well in the Wayback Machine snapshots) it can be a lot of work to dig them up. Getting the original docs all in one place should make them a lot easier to link to (as I do pretty often). |