I am asking how to switch from client1 to client2 where client1 belongs to stream1 and client2 belongs to stream2.
What I am looking for it to do the same as being in p4v and then right click on a workspace and selecting 'switch to workspace'
Note, that if your current workspace is client1 and you use:
p4 client -s -S //DEPOT/stream2
or
p4 client -s S //DEPOT/stream2 client2
it won't change the workspace in the p4v GUI.
There are several different concepts here.
You can have a single workspace, or you can have multiple workspaces.
Each workspace has its own root directory on your workstation, and its own copy of whatever files you have most recently sync'd.
If you have a single workspace, you can switch that workspace back and forth from one stream to another, by using the 'client -s' command to switch the stream to which that workspace is bound. This way, you can alternate between working on one stream, and working on another, using a single workspace. In the most recent versions of the Perforce server (2015.1+), there is even a 'p4 switch' command which makes this process simpler still.
Switching your single workspace from one stream to another on the command line using 'client -s' is the equivalent of dragging and dropping your workspace icon from the old stream to the new stream in the Stream Graph, more or less.
You can also have multiple workspaces, each with an independent set of files sync'd, and you can work with each workspace separately. On the command line, to switch from one workspace to another, you simply change the way that you tell the 'p4' command which client you want to use, which you can do with the P4CLIENT variable or the '-c' flag to the client. For example:
p4 -c client1 sync
vs
p4 -c client2 sync
tells the p4 client to sync first client1, then client2. Alternately, you can do:
p4 set P4CLIENT=client1
p4 sync
then
p4 set P4CLIENT=client2
p4 sync
to accomplish the same effect (switching between one workspace and the other at the command line).
P4V, however, has its own notion of the "current workspace", which is separate from the command line, and I don't believe that just changing your P4CLIENT variable is enough to perform the P4V operation of "right click on a workspace and selecting 'switch to workspace'".
The closest thing you can get to a command-line command which changes which workspace P4V considers to be the current workspace, I think, is to invoke a different copy of P4V from the command line, and specify a different client name when you do so, as described here: http://www.perforce.com/blog/100114/p4v-secrets-calling-p4v-command-line
But I think this will get you a new P4V window with the other workspace, rather than changing the current workspace of your current P4V window.
Another possibility you could try would be to use one of the Windows GUI automation tools, such as Autoit (https://www.autoitscript.com/site/), to create a script which will use the Connection menu on the menu bar and operate the Switch to Workspace... dialog via Autoit.
Related
When issuing a p4 command e.g. p4 client no matter current working directory is inside or outside the perforce workspace, the command output is
Error: p4 client root is not '/workspace_dir'.
Please make sure that your Perforce workspace has the 'Alt roots' set to '/workspace_dir'.
P4V client works ok.
How can change 'Alt roots' setting?
Run the p4 client command to edit your AltRoots.
If you do not have multiple client roots (which is a pretty rare situation), you do not need to set the AltRoots field. The error you quote is not a Perforce error that I'm familiar with and may be some sort of wrapper script or trigger that is configured to expect an AltRoot for reasons that may not be sound. I'd check with your Perforce admin for clarification.
I am trying to automate access to Perforce via it's command line utility.
Creating a new client workspace with p4 client and syncing works ok.
Now I am allowing users to overwrite user, host, port, stream, revision.
From the docs it is not clear to me when I have to execute which commands to get the client workspace files in sync with an edited client workspace spec.
What I currently do is once p4 client is through search for
Client mymachine not changed
in stdout and do a p4 sync -f should the message not appear.
Is there a better or more sane way to do this?
I tried executing e.g. p4 sync -s in hope that it would fail should local data be deleted but it seems that I misunderstood the option?
It is not clear to me how this relates to your question about workspaces:
Now I am allowing users to overwrite user, host, port, stream,
revision.
since only one of those is a property of a workspace. I'm going to disregard that statement for now but if it was significant I'd encourage you to post a follow-up clarifying what you mean by "overwriting" each of these properties.
To your question:
From the docs it is not clear to me when I have to execute which
commands to get the client workspace files in sync with an edited
client workspace spec.
If the client View is updated, all you need to do is:
p4 sync
If the client Root is updated, or any of the other options that globally affect how files are written to the workspace, such as allwrite or modtime, you will need to re-sync the entire client. Ideally this is done by doing:
p4 sync #none
prior to changing the workspace in one of these ways. The other option would be to do something like the following sequence:
p4 sync #none
p4 sync
p4 clean
to make sure that everything is rewritten, and that any stragglers (e.g. anything that the "sync #none" couldn't locate because the Root had changed but that are still mapped in the client view) are removed from the workspace.
I tried executing e.g. p4 sync -s in hope that it would fail should
local data be deleted but it seems that I misunderstood the option?
Deleting local data is a separate issue from editing the client spec, but for that the command you want is p4 clean rather than p4 sync -- you use sync to tell the server you want it to send you new revisions, you use clean to bring your workspace back in line with what the server already sent you.
The recommended/supported workflow is to always use p4 commands to manipulate the read-only files in your workspace -- so if you want to delete a local file, use either p4 sync FILE#none (to remove it from your workspace but not affect the depot) or p4 delete FILE (to open it for delete so that it will be deleted for everyone when you submit).
The title may be misleading but I need to know more terms and more about P4V to properly summarize the question. That's also why I cannot get the answer by google.
I delete a workspace by mistake. Choose view->workspaces, and then the right pane list the workspaces I have. I delete one. And that's the one I have on another machine.
Files stay on the disk of that machine. But P4V do not show this workspace anymore. I plan to open a new connection, create a new workspace and set the same location. But I'm afraid that the sync operation will override the folder. That's not what I want. Because except from the source codes I get from depot, I have built the code. If overriden, a lot of build work has to be redone.
So, how to recover my workspace in perforce?
The situation is very similar to the one described in this KB article: http://answers.perforce.com/articles/KB/2446
After you have re-created the workspace, do not sync. As you say, it will overwrite your files (at least the read-only ones), and you don't want that.
Instead, open a command prompt and run:
p4 sync -k ...
p4 clean ...
The "p4 sync -k" tells the server to do a sync but keep what you have in your workspace instead of overwriting it. The "p4 clean" tells the server to verify what's in your workspace against what you just told it you have, and refresh any files that are different.
Do you happen to have a spec depot? Just view the client (you might have to "Show deleted depot files" if you don't already have that set up. If not, try to create a new one with the same settings (I'm hoping they were easy to remember). Do not sync the new workspace. Instead, do "p4 flush", details at p4 command info . This will make the server think you've synced to latest, but won't touch what you have on the workstation.
What will happen if I cancel p4 sync during operation and then call again? Will it do all the work it has already done again?
And another one question: how and where does p4 store information about workspace file revisions? How does it know that I have n-th revision in workspace?
Does it store such a local workspace-specific information on the server's side or locally?
If you interrupt a "p4 sync", it will pick up where it left off (at the file level of granularity -- if you're syncing a single large file it'll start over, but if you're syncing a lot of files it'll start with the next file after the last one that was synced successfully).
Information about which file revisions you have in your workspace is stored on the server. Run the "p4 have" command to see this information for your workspace. You can also run commands like "p4 files #otherclient" to see which revisions another workspace ("otherclient") has synced (e.g. if you're trying to reproduce a build from another workspace).
I am writing a build script that gets all the source code for a particular changelist and builds it. I would like to be able to run the script at any time, without having to shelve local changes or move files to a temporary location. The script will be used by others who have their own workspaces defined.
I thought it would be easiest just to get all the source code from Perforce at a temporary location and build from there. Unfortunately p4 sync does not seem to support this, it will only put files into the client view as specified by the workspace, meaning it would overwrite local changes before I could copy the files to the temporary location.
Is there any way to use p4 to copy files from Perforce into an arbitrary location?
You could create a dedicated workspace for the build script and then have the build script sync to it by using
p4 -c [workspace name] sync [depot path]
This is what a continuous build system would typically do. Be sure to blank out the Host: section of the workspace spec in this case so that it can be used on multiple systems.
An alternative might be to use p4 print with the -o option to dump the files to an arbitrary location without syncing them.
P4 sync can be done only to a client spec. Possibly, you need to create another client spec and sync to that client spec.