Perforce cmd line option to populate workspace - perforce

I am new to Perforce and have some experience using ClearCase earlier. I am using a Windows XP client and trying to set up my perforce client/workspace.
The Perforce view I have has mappings of type:
//depot/path/to/folder/... //my_workspace/depot/path/to/folder/...
However, I have not attempted the "Get latest revision" action (in p4v) for this workspace. That means, I don't have a local copy of the folder in question.
My question is: How do I populate the workspace with contents of the folder from the command line when the folder isn't present in the workspace ? The manual for p4 sync talks about getting a certain revision when the file is present in the workspace.
In terms of ClearCase, when the config spec for a snapshot view is having loadrules too, then cleartool can be told to pick the config spec from a text file and also load the contents of the view. I am trying to achieve a similar thing for Perforce.
Thanks in advance,
Parag Doke

Running the sync command will populate the workspace. If a file or folder isn't already present, it will be created during the sync operation.
With no additional flags specified, p4 sync will populate your workspace with the latest contents at the time the command is started.

Related

How can I synchronize(submit) my local folder with depot, when I have lots of redundant files deleted manually from workspace,

I have never used P4 version control system before, and just come across with following problem:
I was submitted a project to server with lots of redundant files and have been working on the project actively. Now I have my project working and clean, and want to synchronize with depot. The problem is that I have deleted lots of files manually in windows file explorer(from my workspace),ignoring the rules of p4(mark for deletion, submit etc.).
How can I synchronize my project with depot? With another word, how can I delete files from depot that I have manually deleted from local folder, which are not shown in "workspace" tab.
Run the command:
p4 reconcile
This will automatically scan your entire workspace for added/deleted/modified/renamed files and open them for the appropriate actions. Once you've run reconcile you can just p4 submit as normal, and everything you did in your workspace should get submitted to the depot.
If you're using P4V, I think there's a "Reconcile..." menu command that will do something similar.

P4V how to recover a deleted workspace

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 is the relationship between workspace and working directory

I've been reading about Perforce but haven't found any comprehensive explanation of relationship between workspace and working directory, e.g. how files appear in working directory from workspace, how they are tracked, what inconsistencies are possible between workspace files and working directory files etc.
I come from git background, and so I'm looking for the description of workspace and working directory interaction similar to index and working directory interaction in git.
For comprehensive information, the full Perforce documentation is available online. But here's a basic summary of the terms and concepts:
Perforce is a client-server system. The server tracks changes to files. Developers perform modifications to files using copies of those files on their machines, arrange those modifications into units called changelists, and submit those changelists to the server when they are ready.
All information about files is stored on the server. A client, or workspace, is a set of configuration data about a single copy of versioned files stored on a developer's workstation. For each workspace, the server keeps track of: which files are currently sync'd to that workspace, which pending changelists are being constructed, which user is using those files, in which directory on which computer the workspace resides, etc.
Getting a copy of versioned files into your workspace is called sync; submitting a new changelist with new file versions is called submit. As other users submit modifications of files, your workspace gradually becomes out of date; to bring it up to date you issue the sync command, possibly followed by the resolve command to merge newly-submitted changes to files you have been editing.
There isn't an exact analog of the git index construct. Modified files are copied from the developer's workspace on their workstation to the server by the submit command, and then are stored permanently in the server's archives. A somewhat different workflow is available in Perforce called a shelf. You can construct a changelist with modifications, and then use the shelve command to store that pending changelist on the server in shelved state. Pending and shelved changelists have several similarities to the way that git add allows you to assemble a commit prior to committing it, but there are also a number of differences, starting with the fact that Perforce tracks that information on the server, not in the client.
Perfore does not really have the concept of the "index/staging area" that Git does. Files only exist within the Perforce server (the depot) or in your local working directory.
The workspace is just a bundle of configuration data that tells Perforce what files to put where in your local environment.
It is effectively a "binding" that specifies what files to select from the depot and where to place them in your working directory. This flexibility can be incredibly useful in some circumstances, but it is also an extra level of indirection compared to other VCS's such as Git/Mercurial/Subversion.
If you look at the contents of a workspace definition you will see a "Root:" section that points to a location on your local machine, and a "View:" section that tells Perforce what files you want synced to that location.
The Perforce documentation is a bit confusing with regards to its terminology. In the docs I've seen, "Workspace" refers to BOTH the specific workspace definition that you create (which is a data structure held within the Perforce server) AND the local working directory that the workspace is bound to, fairly interchangably. This is because the whole point of a workspace is to bind to a specific local working directory.
Take a look at example 15 here: Managing files and changelists
The output of the p4 sync command shows that it is writing files to the C: drive. When you "retrieve files from the depot into your client workspace" that DOES actually mean that files get copied into your local working directory.
Let's take a workspace definition for example. The key fields for this explanation are Client, Root, and View, so I'll only show those for clarity:
Client: mysimpleclient
Root: /Users/johndough/myspecialproject
View:
//depot/foo/... //mysimpleclient/...
The Client field defines the name of the workspace. The Root field defines the root of the workspace on the local filesystem. The View field describes how files from the server will be mapped to your workspace files. (This adds some flexibility when compared to Git, but at the cost of a bit of a learning curve). I've used a very simple mapping here, but this could be a lot more complex.
Let's break down the View field. Let's say the server has a file //depot/foo/bar.txt.
When you sync (get latest revision) of this file, Perforce will use the view line to determine where the file lands on your filesystem.
Here is our view again:
//depot/foo/... //mysimpleclient/...
The left side is in depot syntax, the right side is in workspace syntax, and it always starts with //workspace_name. The "..." is a recursive wildcard (kind of like ** with globbing). You can mentally replace the workspace name with the value of the root, to make sense of this.
Remember our root is: /Users/johndough/myspecialproject
So, after replacing "//mysimpleclient" with that value we arrive to:
//depot/foo/... /Users/johndough/myspecialproject/...
Let's use that modified view line to figure out where bar.txt will end up:
//depot/foo/bar.txt /Users/johndough/myspecialproject/bar.txt
This is how it works when you pull files down. When you add new files, the mapping is read in reverse. Let's say you create a file /Users/johndough/myspecialproject/fred/file.txt
Our (mentally modified) view is:
//depot/foo/... /Users/johndough/myspecialproject/...
We interpret this in reverse. Concatenate the relative path of the new file with the root of the workspace:
/Users/johndough/myspecialproject/fred/file.txt
And then do the same for the left side:
//depot/foo/fred/file.txt
Putting it altogether:
//depot/foo/fred/file.txt /Users/johndough/myspecialproject/fred/file.txt
Hopefully this helps. The notion of workspaces is probably the most difficult aspect of getting started with Perforce. Happy coding!

Perforce not syncing files correctly

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.

Integrated files disappear from a pending changelist at p4v

Our user performed an integration between branches.
Integrated files were placed in a pending changelist but they are invisible when I look
at this changelist in p4v.
I can see them when I look on this changelist when I connected to another workspace, I can also see then in Eclipse.
When I choose to Resolve conflicts on this changelist it works too, but
when I try to submit the changes, there is nothing there.
After I installed a new version of p4v, the problematic pending
changelist appeared with a question mark (red triangle with a question
mark).
Any Ideas?
Thanks.
Answer from Perforce support:
This may be a working and locks out of sync
issue. Can you run the following server command:
p4d -r $P4ROOT -xf 925
Where "$P4ROOT" is the location of the db.* files.
P4V.exe allows the user to specify a filter on his workspace. Perhaps the workspace had a filter applied, such that the GUI did not show the files, where the command line client and others (ie Eclipse) would not be privy to this filter and would show the files.
Another possibility is that the user was logged in under a workspace other than his default, and the files were checked out in his default workspace. It would be easy to then find these files in his default by looking at pending changelists for all users.

Resources