[p4] Multi-stream workspaces

[jfaustml]

Posted on behalf of forum user 'jfaustml'.

By far the biggest pain point I've found working with multiple stream depots
is workspace management. I was hoping to be able to create a single workspace,
mapping in streams from multiple depots. This almost works -- I can create the
workspace, get latest in it and make changes, but I then cannot submit those
changes back to the server:
warning: cannot submit from non-stream client
Are there any plans to allow this? Or to make dealing with workspaces easier?
Specifically, I'd like to not have to deal with them directly, and instead
to infer them the path I'm working with.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[P4Matt]

Posted on behalf of forum user 'P4Matt'.

I assume the streams have some sort of relationship with each other? Do they
represent different libraries or components?

A couple options are:

1) Use the 'import+' option to bring the content of streams you are
dependent on into one stream. This is a common approach with component based
development as it makes it easy for everyone who is working together to get a
client with all the dependencies they need. If you are accustomed to Git you can
almost think of import+ paths as submodules.

2) Create multiple stream workspace and use P4CONFIG files so that connections
are automatically maintained for you. This is the way I work. At the root of
each of my workspaces is a text file like this:

P4CLIENT=matt-worrkshop

Perforce will automatically start using the settings in the config file when I
cd into that directory.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[Josh Faust]

Posted on behalf of forum user 'Josh Faust'.

They are separate, unrelated projects. Day-to-day though I may be working on one
or all of them.

We've found stream imports to be inappropriate due to not being versioned as
a commit within their depot --
http://forums.perforce.com/index.php?/topic/3493-atomic-submit-of-stream-import-change-and-project-change/.

P4CONFIG files look like they're exactly what I'm looking for. I will
say the documentation for them is rather confusing -- it's not clear you
have to set the P4CONFIG environment variable to a filename that is the name of
the file p4 will look for to load P4CONFIG variables.

Thanks!



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[Patrick B]

Posted on behalf of forum user 'Patrick B'.

We use streams exclusively now for our 600+GB repository.��If
you'll be at Merge this year, I'd be happy to talk about how we use
them.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[David Yerkess]

Posted on behalf of forum user 'David Yerkess'.



[http://forums.perforce.com/index.php?app=forums&module=forums&section=findpost&pid=14986]

...
1) Use the 'import+' ...

Is this a special type of import that allows submits or are you referring to the
use of import within a stream (and imported files cannot be submitted)?



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[P4Matt]

Posted on behalf of forum user 'P4Matt'.

Special type. import+ removes the read-only restriction for those paths.
You'll need to wait a couple weeks to get your hands on the functionality
though; it's in the 14.2 server. I mistakenly thought it was added in 14.1,
but that is when we added the ability to lock imports to a specific changelist.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[Josh F]

Posted on behalf of forum user 'Josh F'.

How does that commit work? Is it a single atomic commit with all files? Is the
version referenced in the import+ automatically set to the version in that
commit?



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[P4Matt]

Posted on behalf of forum user 'P4Matt'.

Single commit with all files. The import+ and the ability to lock an import to a
specific change list don't play well together; you have to use one or the
other. So I have views like:

import qt/... //import/qt/5.1/***@123456 import+ p4/... //depot/main/p4/...



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[Josh F]

Posted on behalf of forum user 'Josh F'.

So in that case, if there's a separate commit to //depot/main/p4, "Get
Latest" on the importing depot will retrieve that commit, correct?



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[P4Matt]

Posted on behalf of forum user 'P4Matt'.

Yup! It's just like it is a normal part of your stream, it just happens
to live somewhere else.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[Josh F]

Posted on behalf of forum user 'Josh F'.

Unfortunately that's exactly what we don't want. It means any depot
importing that stream immediately receives any change to that stream. So if
someone commits a breaking API change, the importing stream is broken
immediately. Locked imports solve that, but are also not versioned atomically
with a changelist.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[P4Matt]

Posted on behalf of forum user 'P4Matt'.

Yeah, I suspect in the next couple revisions of streams we will need to add an
option to have the stream update occur as part of a submit.

I've been drafting a proposal for the behavior you want. My thought was we
could have the spec be a file at the root of the stream that can get committed
to make the stream view change. Would that do the trick for you?



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[Josh F]

Posted on behalf of forum user 'Josh F'.

Yes! I'd love to see other things, such as the ignore list, work this
way as well.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[P4Matt]

Posted on behalf of forum user 'P4Matt'.

For the ignore list I highly recommend using P4IGNORE files. They are waaaaay
more flexible.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[Josh F]

Posted on behalf of forum user 'Josh F'.

They're also not committed, no?



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[P4Matt]

Posted on behalf of forum user 'P4Matt'.

Definitely can commit those. The one problem is that there is no default value
for P4IGNORE, but that's coming. The p4ignore files work just like gitignore
files. Not quite as flexible, but definitely very useful.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[Josh F]

Posted on behalf of forum user 'Josh F'.

Oh, great. The example in the docs ignores the P4IGNORE file (
http://www.perforce.com/perforce/r12.1/manuals/cmdref/env.P4IGNORE.html ), so I
assumed that was best practice.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[P4Matt]

Posted on behalf of forum user 'P4Matt'.

Yeah.... that's odd. I guess some people do prefer to not check them in, but
I certainly do. I'll file a bug against that page; sorry for the confusion.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[Michael Mirman]

One reason against checking in P4IGNORE files is that different people sometimes want to have different content in those files.

However, in some of our areas of the repository, there are many checked in .gitignore files. The users of those areas all have P4IGNORE=.gitignore and seem to be happy about it.


--Michael Mirman
MathWorks, Inc.
3 Apple Hill Drive, Natick, MA 01760
508-647-7555

-----Original Message-----
From: perforce-user-***@perforce.com [mailto:perforce-user-***@perforce.com] On Behalf Of Josh F
Sent: Wednesday, September 10, 2014 2:00 PM
To: perforce-***@perforce.com
Subject: Re: [p4] Multi-stream workspaces


Posted on behalf of forum user 'Josh F'.

Oh, great. The example in the docs ignores the P4IGNORE file (
http://www.perforce.com/perforce/r12.1/manuals/cmdref/env.P4IGNORE.html ), so I
assumed that was best practice.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces
_______________________________________________
perforce-user mailing list - perforce-***@perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user

[David Yerkess]

Posted on behalf of forum user 'David Yerkess'.

import+ sounds cool! I bet our programmers will be very happy.

What happens regarding submits restricted to stream owner?
Does each import follow the rules of the stream from which it is imported?



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[P4Matt]

Posted on behalf of forum user 'P4Matt'.

That's a good question. I'll have to play with that. We're a pretty
open bunch around here so I've never used an owner restricted submits
stream.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces

[David Yerkess]

Posted on behalf of forum user 'David Yerkess'.

I use the restricted submit with an admin account to "close" a release
branch and make sure nobody can submit without me approving.
I find it a lot easier and faster than the permissions table.

We also use game build streams imported into source streams and viceversa the
source stream imported into a build stream.
If a user by mistake creates a workspace from the build stream, he can't
submit to the build, because a build account is owner and restriction is active.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/3527-multi-stream-workspaces