Summary: What is the equivalent to git pull and git push when using P4Sandbox?
Details:
I'm more familiar with git so I'm trying out using P4Sandbox with Perforce. I've been able to commit my changes in my local sandbox, but I am having trouble pushing them to the central server. I'd prefer to use P4V, but knowing the command line option to complete this task would be great as well.
Submitting changes to the "mirror" stream will cause P4Sandbox to submit to the shared server. Similarly shelving a change to the "mirror" stream will cause P4Sandbox to shelve to the shared server.
In the stream graph of P4V you should will see a stream at the top of the graph with a badge that looks is using echolocation. Right click that and select "Copy to ''". In the resulting dialog select the child stream that has the contents you want to push, enter a changelist description, and press 'Copy'.
From the command line, you can run 'p4 copyup' from the development stream you want to push. This will copy your changes up and switch your workspace. A 'p4 submit' at this point will send the changes to the shared server.
Related
So my problem began when I've cloned a repo from shared server, made some changes and few submits. Then I closed p4v and opened it again. My workspace disappeared but only from perforce view(I still have local changes). And there are no changes on the server. So my question is: am I able to clone repo to the path full of changes without losing them, or at least can I do something to avoid downloading whole repo again.
Greetings and thanks for your time. ;)
I am not sure if you are using DVCS (a personal server on your computer) of if you ran 'p4 sync' to get the files in to your workspace. If using DVCS, 'p4 fetch' or 'p4 fetch -t' will enable you to pull in any changes from the server. If you simply synced the files to your local machine, then you can simply sync any changes. If changes have occurred on the server, you will need to resolve them before submitting. You will be prompted to do this when you try to submit your changelist.b
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).
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.
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'm using Perforce P4V, the graphical tool, to interface with my Perforce server here at work. I have a project I added to the depot and I accidentally deleted it from my workspace on my local computer, problem is when I use the Get Revision Action (the GUI equivalent of sync), the files don't get updated, i.e. I can see the files on the server that I want, but they won't sync correctly with my local PC. It's frustrating me that the files aren't getting pulled from the server. What I'm assuming should be happening is if files are altered in anyway on my local PC, I should be able to grab the revision from the server, which then pulls the data to my local PC and overwrites the changes locally on my PC, but that isn't happening. Is there something I'm missing?
Perforce keeps track of the files that it thinks that you have on your local workstation. If you delete those files locally (and don't "tell" perforce about it), then Perforce will still think that you have those files. If you want to get them back, you need to "force sync" the files. In p4v, you can use the "Get Revision..." item and in the subsequent dialog, you can check the "force operation" checkbox to tell Perforce to give you all the files again regardless of whether Perforce thinks that you need them.
Just to complete the information, if you ever do want to remove the files locally, you can do so through p4v by choosing the "Remove from Workspace" item. Doing so will remove the files locally as well as tell perforce that you no longer have those files so that next time you sync, those files will be retrieved from the server.
Like other people have mentioned, one solution is to do a "force sync" the entire depot which is basically overwriting everything from server into your local. The downside to this is that it could take a LONG time to finish if you are working on a big depot.
Another alternative is to compare your local workspace with the server, then only force sync the files that are missing from your workspace.
p4 diff -sd //Depot/path/… | p4 -x – sync -f
-sd option: Show only the names of unopened files that are missing from the client workspace, but present in the depot.
There are more options (sa/se/etc.) available if -sd is not what you need. see here.
credits for the command goes to this blog.
They won't update because according to Perforce you still have the files on your local machine.
You need to use the "Get Revison..." option and enable the "Force Operation" option.
This will tell Perforce to refresh all the files even those it thinks you have the latest version of.
"Get Revision" will update only files that are not opened (checked out) even when "Force Operation" is enabled. You should revert all files marked as checked out in that workspace, and then use "Get Revision" with "Force Operation"
I did as you suggested, but I kept getting the message that the files were still open for edit and cannot be deleted, when trying Remove from Workspace.
Also, Get Revision returned with a message that no files were updated.
What I ended up having to do was Revert the files, then do the Get Revision action, that solved the problem.
For people coming into this question, this worked for me on the mac command line ...
cd into your local perforce workspace - the base directory of the checked out files that you are working on.
p4 sync -f
-f is to force the sync.
This can also come in handy when you restore a mac from a time machine backup.
https://www.perforce.com/perforce/r12.1/manuals/cmdref/sync.html
Check out the file, change it a little bit and then revert. Perforce will replace the local file with the latest revision.