I'm using P4V to view my perforce workspace. I've changed multiple files in multiple directories within the workspace. Is there a way to create a diff that includes all these changes so I can upload it for code review? I apologize if this is a trivial task. I am new to Perforce and I'm still learning the terminology and the tools after spending a few years with Accurev and Git.
The standard mechanism for code review in Perforce is to put all of the work into a changelist and "shelve" it so that it's visible to other Perforce users before being fully committed. Other users can view the diffs and/or "unshelve" your changelist into their own workspaces so that they can test your changes directly.
http://www.perforce.com/resources/tutorials/shelving-operations-p4v
Related
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!
how to check if any changelist of project A is integrated in project B? and also to get corresponding submitted Cl in project B. Please share any perforce command
It's worth pointing out the unit of integration in P4 is files, not changelists, so the p4 commands are mostly focused around telling you which files are integrated or not. You can, however, find out which changelists still have some files that need to be integrated - use the p4 interchanges command. The Perforce docs explain the syntax.
Assuming that you have a branch spec that describes the relationship of project A and project B called projAprojB, then you can get the outstanding changelists with:
p4 interchanges -b projAprojB
You can also get a similar view of outstanding changes in the P4V Merge/Integrate dialog box.
Alternatively, you can use the 'revision graph' in P4V to see the integrations performed on a given file; doing this on a file from the changelist you want to know about will give you the information to work out if it has been integrated into the other project and the changelist for that was.
If this doesn't suit your needs then your only option is to write a script, either with shell scripting using p4 or one of the APIs provided by Perforce
I am developing an application that is supposed to be integrated with Perforce. In the learning phase of basic Perforce command, I have a question of how 'p4 changes' work. Once a changelist get submitted, say, affecting files at
'//depot/Web/content/main.css'
'//depot/Tool/app/init.py'
If we now issue a command:
'p4 changes //depot/Web/...'
then the changelist will show in the result. So how Perforce manage this information? Does it break down the paths and store? Or does it do an online substring query?
I saw there is a field "common path" in Perforce database schema, in this case, the value should be:
'//depot/...'
So in this case, how does Perforce get the information?
For each change, the Perforce server records which files were affected by that change.
This is one of many pieces of metadata about the changelist which are recorded in the server's database.
That information is used by commands like 'p4 describe' to find the correct set of files.
The Perforce server contains a sophisticated pattern matching engine which can rapidly search through the database to locate the set of changes which affected a certain set of files, as described by a file pattern.
This is a core operation of the server, so it's highly optimized for this behavior.
In our Perforce workspaces at work, there are a couple of control files that contain branch information that should never be integrated across branches.
Is there a way to tell Perforce to always ignore these files in integrations?
You could set up a branch spec and use that for your integrations.
You may be able to use some type of permissions through p4 protect, so that only the admin can modify them. I know this works for actually checking out and checking in a file, but I'm not sure about integrating it to another branch.
You could write a server-side trigger script that looks for the control file names and filters them out of an integrate.
There's pretty good documentation on triggers. There's a load of examples too in the public Perforce depot.
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.