I am trying to get files in the folder A/ which include:
A
|_ A1
|_ A2
|_ _tcp
|_ _bin
and other subfolders under A. However, after running get latest revision for folder A, I can only have A/A1, A/A2 in my local folder but A/_tcp and A/bin are missing. does anyone know the reason and how to solve it? Thanks
There are a few different reasons that a file might not get synced. Running at least one of the following commands on a path that's not syncing should give you the answer. I'll use the path A/bin/... for purposes of this example:
p4 opened A/bin/... -- do you have the file open? If so, your local file is protected from updates until you resolve, submit, or revert.
p4 have A/bin/... -- does the server think you already have the file? If so, it won't re-sync it. Use p4 clean to force your workspace back into a consistent state.
p4 where A/bin/... -- is the file part of your client view? If not, you may need to update your View (or, if this is a stream workspace, your stream's Paths).
p4 files A/bin/... -- does the file exist at all? Is it deleted? If it's deleted, maybe you want to sync an older revision?
p4 protects A/bin/... -- do you have access to the file? If not, talk to your admin.
Related
I'm new to perforce and somehow I've gotten myself into a weird state.
I have two files that I modified and somehow added to a change list (not the default changelist). I want to revert the changes and delete the changelist but I can't figure it out.
I have tried doing this:
p4 change -d 75697
Change 75697 has 2 open file(s) associated with it and can't be deleted.
So I tried to revert the files in the change list:
p4 revert package.json
package.json - file(s) not opened on this client.
Okay, so I guess I need to open the file?
p4 edit package.json
//a/b/c/package.json - can't edit (already opened on this client)
So I can't revert the file until I open it but I can't open it because it's already open? What's the deal?
You could be getting that error because your local package.json doesn't map to the actual depot path that's open (due to something tricky you've done with your client view since opening the file). It's hard to say without seeing more command output, but try just:
p4 revert -c 75697 //...
to revert all files in that changelist regardless of their paths.
If that doesn't work, check with your Perforce admin; either they've put you into some really weird permissions bind (i.e. they've revoked the access level to the files that you need in order to revert them) that they should undo, or they'll need to do a bit of light db maintenance (p4d -xf 925) to fix an inconsistency.
I have a lot of files within the file structure of the perforce depot that I am unable to see with the perforce clients p4 command line or p4v gui even when logged in as admin.
I have tried to find any meta data I can through p4 files and p4 filelog commands but it always returns:
"- no such file(s)."
Also I have run p4 verify and p4 dbverify to see if there we were any errors on the server but they returned no errors. There just seems to be no records of the files except for the fact that they are taking up room on the HDD.
My current theory is that they are from failed commits but I do not know how to get perforce to acknowledge the files so I can obliterate them.
Background info:
This is a simple perforce setup with just the main depot and an archive depot for old projects. (The mystery files are in the main depot)
The server version is: P4D/NTX64/2012.2/551823 (2012/11/09).
There isn't necessarily a one-to-one mapping between what's in the server's depot filesystem and the actual structure of the depot as defined in the metadata -- depot revisions are written once and are not moved or duplicated even if they're moved or duplicated from the point of view of the client. So you definitely shouldn't make the assumption that because a given file in the depot filesystem doesn't correspond to a depot file path that it's not actually providing the underlying storage for some other existing file (especially if you've used obliterate on some branches of a file while leaving others intact -- the remaining archive file may be the content for one of the ones you left).
That said, it is also possible for archives to become "orphaned" as part of a failed submit as you suggest. If the amount of space involved is small I'd suggest not worrying about it (the orphaned files won't cause any problems in terms of collisions), but if it's important to be able to clean them up, your best bet is to use "snap -n" to make sure there aren't any of those dependencies and then delete them manually (just to be safe I'd keep a backup of them at least until you've run your next verify to make sure nothing important has gone missing). Run:
p4 snap -n //... //depot/path/to/mystery/file
This says "show me files anywhere in the depot (//...) with archive dependencies on //depot/path/to/mystery/file". If you run the command without the -n it will actually break those dependencies by making physical copies (don't do this if you're worried about space since you'll end up with N redundant copies of the archive).
The inverse of p4 snap -n (i.e. "where does the archive for this depot file live?") is p4 fstat -Oc //depot/file.
I'm trying to open an existing Perforce application. I made some local changes, like deleting files, which I want to undo (that is, I want my local copy to exactly match the repository once more -- delete added files, restore deleted files, and undo changes).
When I try to revert using the p4v gui client, I see this error:
file(s) not opened on this client
What am I doing wrong?
I did manage to revert all the changed files, but not the added/removed files.
Edit: I did the following:
Connect to a Perforce server using p4v
Map a directory to my local file system (lets say C:\Perforce)
Get the latest version of the repository
Go to C:\Perforce in Windows Explorer
Delete some files and folders
Add some files and folders
I would like to get back to the "pristine" state, the copy of exactly what's on the server when I got the latest version of the repository for the first time.
By the looks of the edited description you added and deleted files directly on the filesystem and not through perforce. Therefore Perforce doesn't know anything about those changes so there is nothing to revert. Typically when you want to add a file you use 'p4 add" (or the equivalent p4v operation), and when you delete, you should use 'p4 delete' (or again, the equivalent p4v operation).
Really, the best option to get back to a pristine state is to nuke the local copy of the code in c:\perforce (in windows explorer), go to p4v, right click the area you want to sync, and choose "Get Revision..." and in the subsequent dialog, make sure that the "force operation" checkbox is checked. This will tell Perforce that you want a new copy of everything regardless of whether you had it synced or not.
You can also run "reconcile offline work" in p4v. Right click the depot area and choose that option. It will scan through the local folder structure and give you a report of what files have been added that don't exist in perforce, what files were deleted, and what files were modified. From that dialog, you can right click on local files that don't exist in perforce and delete them, or you can 'p4 add' them. You can also sync deleted files.
HTH.
Just an extra not to point out another cause for this.
If the file name contains an unusual character that cannot be translated correctly the name on the client will never match that on the server.
The solution in this case is to spot that character in the file name (it will be a question mark emblem on Linux) and use a wildcard to help identify the file to the server so it can delete it etc (p4 deleting the file is a way to go).
This answer may not be your case. This happened to me when I edited the files on my local disk without logging into p4.
A quick fix at commandline is:
p4 login # make sure you've logged in
p4 edit <filename> # let p4 know you've edited the file
p4 revert <filename> # revert to "pristine" state
You can use p4 reconcile -w to restore your client to the state of the server. There is an alias called clean, which is also available in P4V on the right-click context menu as Clean....
There are several additional flags to control whether added and deleted files are deleted or restored, respectively.
The -w flag forces the workspace files to be updated to match the
depot rather than opening them so that the depot can be updated to
match the workspace. The -a, -d, and -e flags when used with -w
update workspace files as follows:
-a Files with no corresponding depot file are deleted.
-d Depot files not in the workspace are added.
-e Modified files are restored to the last version synced.
I want to get files from Perforce without putting them into a workspace.
E.g.
I have made changes in 2 files.
file1.cs
file2.cs
Now I want to build the project using updated file1.cs, so I want to get latest files except for file1.cs.
I thought I will get another local copy of project and build it.
I'm not sure what you really want to do, but you can get the contents of a file from the depot without using a workspace definition by using "p4 print". Example:
>p4 print -o fileName.cs //depot/path/to/fileName.cs
As far as I am aware you cannot sync files from a Perforce depot without using a workspace since this is the way it tracks what version of files you have in your workspace and also where to put them on your local machine (as well as a few other things).
I'm not sure I entirely understand your problem but if what you need to do is get another copy of the file1.cs you have in the depot without removing the changes you have to it you can simply copy the changes to another location or shelve them and re-sync the file. The more complete and less dangerous solution is to create another workspace pointing to a different physical location on your machine but the same depot location.
This explains how to create a workspace if you need it:
http://www.perforce.com/perforce/doc.062/manuals/boilerplates/quickstart.html
Make sure the 'Root' path is different to that of your current workspace, you can check what your current workspaces root is by going to the workspace tab in P4V and viewing it.
Once you have created the new workspace create a new connection and select it then sync the file(s) you need.
So I want to get latest files except file1.cs
You shouldn't do that; you should update all files and resolve any conflicts with file1.cs
Consider the situation where someone else has made changes to file56.cs that relies on changes also made to file1.cs. If you take their changelist but overwrite (or do not take) their file1.cs, then your build will break.
Shelve file1.cs so you can safely revert your local change:
p4 shelve file1.cs
p4 revert file1.cs
Now you can do your build with whatever version of file1.cs you want (you can sync back to an older version or whatever).
When you're ready to return to your change:
p4 unshelve -s CHANGE
If you're in the UI you can use File->Export To... which will copy the selected file to any folder you want.
I found the workaround but not the solution.
I get another local copy of project then build the project and submit the change.
I found an easy way of doing this with git:
$ git p4 clone //depot/your/folder
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."