Dear,
I found I made a mistake recently by using p4 sync command, where I put extra space between "..." and #123456.
It supposed to be "p4 sync ...#123456", but I used "p4 sync ... #123456"
Could anyone help explain what it can happen with this wrong command ? I didn't feel diffference, but someone told me it is wrong, I would like to understand and figure out more here.
Thanks.
Wangyang
Spaces separate arguments (in any CLI app, including p4).
Perforce lets you combine a file specification and a revision specification into a single argument. When they're combined, you get their intersection.
Most p4 commands that operate on files accept multiple arguments, and when multiple arguments are specified, it's equivalent to invoking the command on each arg individually, so the net effect is usually a union (although not all commands are idempotent or combinable, so interactions that make it not exactly a union operation are possible).
Hence:
p4 sync ...#123456
means "sync everything under the current directory ... to the revision #123456".
p4 sync ... #123456
means the same as:
p4 sync ...
p4 sync #123456
that is, "sync everything under the current directory ... to the head revision, and then sync everything in the workspace to the revision #123456."
If the current directory is the workspace root, then the net effect of these operations will be the same (although the command might do some extra work in syncing everything to #head before it syncs it back to #123456). If the current directory is a subfolder in the workspace, the effect will be very different since you'll sync a bunch of other stuff in your workspace to #123456 that the first version of the command wouldn't.
Related
I have a large perforce client already synced. I realized that I'll only be working on a sub directory of the larger root folder I synced to.
Old p4 client specs
//Depot/largeFolder/... //Clinet/largeFolder/...
New p4 client
//Depot/largeFolder/samllSubDir/... //Clinet/largeFolder/smallSubDir/...
Now when I perform a p4 sync perforce doesn't remove the other folders which I don't want in my client.
I'm hesitant to do a p4 sync -f since I have files edited in the /largeFolder/smallSubDir/. I don't want them to get reset.
What is the right way to sync my client so that the other folders which are not in the new mapping are removed?
Note: My real mapping is complicated and deleting folders by hand is not realistic.
In the typical case, re-syncing a narrowed client will indeed remove the unmapped files. You don't say what happens when you try to do a sync (are there error messages?), so I can't say for certain what's going on, but these are the two first possibilities that come to mind:
Opened files will not be touched by a sync, ever. You need to revert them -- use the -k flag if you want to revert the files but keep your local copies, and then use the -k flag on sync as well so that it will continue to not touch them (while marking them as having been synced, or in this case un-synced).
Writable files will by default be left alone by a sync, and produce "can't clobber" warnings. Doing sync -k should suffice here if you want to keep the local files. Doing sync -f will blow away the local files even if they were modified (but only if they're not also open for edit -- see above).
Useful commands to run if you're trying to debug (pick any file that's not getting [un]synced that you think should be):
p4 sync <file> -- do you get an error message that tells you why the file isn't being removed?
p4 where <file> -- is the client mapping for that file not what you think it is?
p4 opened <file> -- is the file opened?
p4 have <file> -- did you even sync this file in the first place?
p4 files <file> -- does this file even exist in the depot?
Note that the fact that opened files will not be touched by a p4 sync means that your edited files will be safe from a sync -f, provided that you actually opened them for edit. If you didn't, run a p4 reconcile and then p4 sync -f is perfectly safe -- but if you don't get to the root cause first (i.e. are the unwanted files also opened for edit?), it might not be helpful either.
My p4 client version is P4/NTX64/2018.1/1705517.
I noticed that some files had accidentally been deleted in my workspace. I synced, but even so, the files did not appear.
I then ran the p4 have command and saw that it contained the missing files, and so p4 will not include those files in the sync.
Of course I can give the p4 sync command with the -f flag, but my workspace is rather large, so that would take a long time.
I then ran the flush command even with the -f flag thinking that it would correct my have list to reflect what I actually had on the filesystem of my workspace, but it didn't. What am I doing wrong?
p4 flush changes the have list to match whatever you tell it to match (if no arguments, then #head is the default). If that's not what your workspace actually contains, then the have list is now out of sync with the workspace, and future p4 sync commands will probably skip a bunch of files (exactly like you're seeing now).
The command you want is p4 clean, which syncs your workspace to match your have list. (If you have changes in unopened files, including "new" files that you haven't opened with p4 add, this will irrevocably blast them. Careful!)
If you want to open the files that don't match your have list, use p4 reconcile instead. (You can follow it up with p4 revert to discard the changes, or p4 submit to keep them permanently.)
In P4, I only want to pull file changed my client workspace from server. But When I use "p4 sync", this command get all files from server. So, How to get files changed from list revision ? with the files were existed on local and not changed, the command P4 sync do not need sync. My command is here:
p4 sync -f //depot/...#Revision
If you want to restore a file you deleted with p4 delete file, use p4 revert file, not p4 sync. p4 sync is for getting the changes that other people made to the files, not for altering the changes that you made.
There are three different reasons that the files in your workspace might differ from the current head revision in the depot:
A new revision has been submitted to the depot since the last time you synced.
You have opened the files (e.g. with p4 edit) and made changes to them that are not yet submitted.
You have modified the read-only synced files in your workspace without opening them.
(You don't say in your question which of these is the case, which is why you've gotten a couple of different answers that are based on different assumptions about your workspace state -- I'm guessing it's #3, personally, but I'll give the answer for each one so you can understand how it's "supposed" to work vs what's actually going on here.)
In case 1, a normal p4 sync command will update only the files with new revisions. If the revision you previously synced is the same as the head revision, p4 sync won't update it. This makes p4 sync very fast -- you can have a million files in your workspace, and if only one of them has changed since you last sync, only that one file is affected.
In case 2, no p4 sync command will update the files, in the interest of preserving your open changes. To submit your changes to the depot, use p4 submit; to discard them, use p4 revert. Again, only the open files are affected by these commands, so a revert operation affecting only a few files isn't slowed down by however many other files are in your workspace.
In case 3, your workspace is in an inconsistent state -- Perforce's standard workflow is that any time you modify a local file you should "open" it so that the server can track your local work (and optimize operations like sync, submit, etc, as well as alert other users who open those files simultaneously to potential conflicts). If you modify a file locally without modifying it, commands like sync will no longer work as well because the state of your client is not known to the server.
You can recover from an inconsistent state by using the p4 reconcile command (which will open all the inconsistent files so that you can either submit or revert them), or the p4 clean command (which irrevocably discards the inconsistent local changes, as if you'd done p4 reconcile immediately followed by p4 revert). These commands are significantly slower than a normal sync operation since they need to scan the entire workspace rather than only the changed files, but they are still significantly faster than a sync -f since only the changed files are actually re-transferred.
I am new to Perforce and want to create a automated tool to get the latest revision by itself. I have a mapping like this:
P4CLIENT: Proj_name
Worspace root direcctory: C:\...\Proj_name
Stream: Build
Now what i desire is it should get latest revision of all files from:
Build\fold1\fold2 to C:\...\Proj_name\fold1\fold2
When I just ran p4 sync command, it copied all files from Build to C:\...\Proj_name.
So please tell how to specify the folder path from where to get the latest revision. Will the command p4 sync //depot/proj1/... work for me and how does it change in my condition ?
You use the View: section of your client spec to describe which parts of the overall repository you wish to work with, and where those files should be placed on your workstation's filesystem.
In your particular case, to specify the folder path, as well as where those files should be placed, you might specify your View: as something like:
View:
//depot/Build/fold1/fold2/... //Proj_name/fold1/fold2/...
You may have considerably more complex view mappings; the view syntax is quite powerful. To learn more about view mappings, type p4 help views.
After you change your View: specification for your client, run:
p4 sync
The sync command will notice that you have changed your view mapping, and it will re-arrange the files in the root of your client on your workstation, so that they are arranged as described by your new view mapping.
If you don't wish to sync your entire client, you can specify a subset of the files which should be sync'd, by naming that subset of files using a file pattern as an argument to the sync command:
p4 sync //depot/Build/fold1/fold2/*.cpp
However, that can be quite confusing, and I recommend that, to start, you avoid using that advanced usage, and stick to performing a p4 sync with no file arguments, at least until you get more comfortable with how p4 sync is used. For one thing, when you are sync'ing different subsets of files with different file arguments, it is quite easy to get your workstation's filesystem into an un-buildable state, by getting half of the files from one changelist and half from another, which will cause you to have code that doesn't compile, etc.
So, for now:
Consider which parts of the repository you wish to work with, and where you want them to go on your workstation's filesystem
Run p4 client and describe the appropriate View: line(s) to specify those files, using the pattern-matching syntax of the View: field
Run p4 sync and Perforce will put those files on your computer as specified.
If you do a sync in perforce it can happen, very often, to do nothing even if it should. If you do a forced sync (sync -f) it will definitely sync all the files from the server blindly and this is unacceptable if you have a big project.
The question is how can you do a fast sync?
The key part to your question is "even if it should". Without fail, in all my (too) many years of experience with Perforce, users who revert to forced syncs habitually, because a normal sync does not do what they expect, are not using Perforce correctly.
You must let Perforce manage your hard disk for you - the server knows which versions of which files you have, and so a normal sync just gets what it needs. If it fails, then that is almost without exception a sign that the user is modifying, deleting, adding, renaming files outside of Perforce (e.g. in Explorer).
Sometimes you may get a system funny (i.e. PC fault, ) that causes this, so it is not necessarily the users fault. But these are very rare - hence my "habitually" qualifier above.
If you think, hand on heart, that you are not doing anything out of the ordinary, then start to look at what other processes could be tweaking these files. E.g. does you build system do something odd, and try to modify files as it builds? Do you have an open network share that perhaps someone else is inadvertently poking? Do you have a backup system that is interfering?
Hope that helps.
As mentioned by the other answers, you need to create a separate client (workspace) for every "instance" of a directory tree synced from the depot.
If you want to force-sync only those files that have changed from the depot:
p4 diff -se ... | p4 -x - sync -f
p4 diff -sd ... | p4 -x - sync -f
Warning: that will overwrite any locally changed files (in the current directory and subdirectories).
If instead you edited some files and forgot to open them for edit first, you can do this:
p4 diff -se ... | p4 -x - edit
which will open for edit any file that's different from the depot.
And this:
p4 diff -sd ... | p4 -x - delete
will open for delete any file that was locally deleted.
If you create an inconsistency, where perforce looses track of what is going on in your workspace, you should use the "Reconcile offline work..." function (in P4V).
This will run a folder diff and tell you what options you have to resolve the inconsistencies.
In general, make sure that you always check out files explicitly through perforce (open for edit). This feels strange if you are used to other systems.
I believe that the command you're looking for is p4 clean.
From: http://www.perforce.com/perforce/r14.2/manuals/cmdref/p4_clean.html
"Files present in the workspace, but missing from the depot are deleted from the workspace.
Files present in the depot, but missing from your workspace. The version of the files that have been synced from the depot are added to your workspace.
Files modified in your workspace that have not been checked in are restored to the last version synced from the depot."