In the 2009.1 version of Perforce Visual Client for 32-bin Windows, the "Reconcile Offline Work" option does weird things. In the middle box where the "Local files not in depot" should be displayed, I never get anything. What I do see is that the first time I reconcile a folder, it looks like perforce is filling the box with the "local files not in depot" because a list flashes quickly before my eyes. Then all of a sudden, the list quickly disappears into thin air and I'm left with an empty list. Does anyone know how I can get this feature to show me the files that I have not yet added? It seems like the "Modified files" and "Depot files missing from workspace" features work fine.
Also, as a side note, "Reconcile Offline Work" seemed to work fine in the 2009 beta version.
I had exactly the same problem.
The solution for me was obscure but trivial.
I simply changed the root directory of my client workspace from "C:\depot" to "c:\depot".
Yes, that's right, all I did was to change the drive letter from uppercase to lowercase. And, yes, I verified that changing the drive letter back to uppercase breaks it again and that changing the drive letter back to lowercase again fixes it again. So, this is not just a coincidence.
This is almost certainly a bug in the Perforce reconcile feature.
If you look closely at the reconcile paths, they all appear with a lowercase drive letter, even if you specify an uppercase drive letter, so my guess is that the matching algorithm is simply doing a case-sensitive comparison on the file paths. This is appropriate for everything but the drive letter. Their file lister probably always sets the drive letter to lowercase, so an uppercase drive letter on your client workspace root will never match.
This certainly sometimes happens. I seems the problem is likely to occur if I change the workspace view somehow and/or upgrade P4V to new version. So the solution which worked for me in the past was to trash the problematic workspace and create a new one (sometimes have to choose a different name too).
Perhaps deleting the .p4qt and .p4scc in your user home directory can help too.
Incidently, I did have a conversation with Perforce support on the related subject some time ago, and as the problems like this are very difficult to reproduce, therefore there wasn't much that they could do.
I have found issues with long filenames in p4 reconcile
from the base direectory
p4 reconcile ./...
never returned.
but if I cd further up the tree
cd components
p4 reconcile ./...
worked.
I was able to reconcile the whole tree eventually by stepping up directories, depending on how much longer your paths are this might work for you.
I had an instance where p4v showed the visual indicator that files had changes, and doing a diff showed the changes appropriately, but resolve on any parent directory didn't show them.
Those files had been changed by downgrading a library using a unity package install, and their "last modified" date was older than the previously submitted files. On OSX running the touch command on all the files in relevant directories updated all their modified times and reconcile worked after that.
Related
In my workspace when I run p4 status, it marks a bunch of files as "reconcile to edit". However, if I reconcile them and do a diff, all these files are identical.
Does anyone have some idea on what would be the cause?
These files include png, js, php, ttf, xsl files.
I have my workspace configured with: "Allwrite" and "Line ending characters for text files: UNIX" (this is a Windows 2012 R2).
I was guessing the Line ending was the cause, but the files include png, and after I actually submit the changelist and do p4 status, it still report the same list of files (well, I notice a few files are gone, to there maybe something there for whatever reason).
My workspace is new, so the files really shouldn't have any changes.
One possible cause of this is that the stored checksums don't match the actual file content. As an admin you can run:
p4 verify -q files ...
to do a server-side comparison of files vs their stored checksums -- if you get "BAD!" results it means they don't match each other (which means they'll also always show up as "different" on client machines since the same checksum is used there). Checksums not matching depot revision contents can be a bad thing (a given revision is supposed to be immutable) and should prompt investigation since it might indicate hardware failure, tampering, et cetera. There may also be benign ways a revision's content can change so it no longer matches its checksum -- one example is if you have dynamically expanded $DateTime$ keywords in the file and you change the server's timezone.
If the content is fine and you want to update the checksum to match, do:
p4 verify -v file
It seems like there could be several reason for this behavior. #SamStafford answer may surely be one of them.
In my case, it turns out that those files has versions that differ by capitalization. Since Windows is case insensitive, that's what messed it up and always marked them as changed.
The OP mentioned "I was guessing the Line ending was the cause" in the question, but this was a little cryptic for me and I missed how this was in fact exactly what I happened to be looking for.
In related question & answer https://stackoverflow.com/a/49803790/74296, #Samwise explains that the workspace line ending configuration "Shared" can cause this when a file is stored in perforce as "Windows style" line endings.
I've googled this, and saw that someone had a similar problem here -> stackoverflow, but as luck would have it, unresolved.
I have an issue where my P4 client is not able to see or access any submitted files that are newer than 4 months old.
Background - My root directory/db files are on D drive which is undisturbed. I got a nasty virus yesterday, so I checked in all my workspace stuff and recovered to a December drive of my OS. Now that I've successfully booted up in my December version of my OS (where the same version P4V and P4A is already installed), my P4V is only able to see and access files up to 12/15/2015 - nothing after. The drive image I recovered from is dated 12/19/2016. Yet, I can physically inspect all my post Dec P4 checkins in the physical location of my DB on D drive. It's ALL THERE.
Here's really interesting info - out of curiosity, I recovered back to my Virus laden OS from yesterday. Opened up P4V, and it is able to see and access all my files up till my very last submitted file which was checked in yesterday.
Other important into
- The depot, stream, and workspace that my p4 is using is the same between my recovered Dec recovery OS, and yesterday's Virus laden OS. Nothing was ever changed in my P4 settings.
System info:
Windows 10
P4V and P4A - NTX64/2014.3/1007540 (for both my recovered windows image from Dec, and yesterday's virus laden windows)
P4 is my achilless heel. Help appreciated. I will not take offense if you explain things to me like a 3rd grader.
Cheers,
Paul
First off, I used incorrect terminology in my original question. I had my depots on D drive and everything else in their default locations on C.
Where I had it wrong: in the belief that as long as I had my depot files backed up to a safe location, I was protected. There is more to it than that :|
What went wrong: When my PC crashed, I recovered to a 5 month earlier December version of my Windows install which means (obviously) I have December's install of P4 with database files only aware of files I checked in up to December. I did indeed have 1000s of files check in after Dec, all alive and intact, but P4 is simply unaware of it. An assumption (which I had) that P4 simply peeks into the Depots to stay up to date of their contents is an incorrect and dangerous one.
To those who may benefit: For those do-it-yourselfers, these are the 2 things in Perforce you should be backing up if you want to be able to do a full recovery later down the line when things go bad:
Database files. By default, they live in the Perforce application’s “server” directory. For me, there are 67 database files in my C:\Program Files\Perforce\Server. They are all prefixed with db.* and it’s these files that P4 uses to “know” the current state of things, like, your changlists, checked-out files, all your workspaces and their settings, depots and their settings, etc, etc etc. Oh, and what files you even have in your depot! Unfortunately, when backing up database files, you can’t just copy/paste them, but must use command line commands to properly generate 2 other file types (journal, checkpoint) specifically for recovery purposes. It is these files that you'll generate new database files from in a recovery operation.
Depot directories. Depots specify directory trees that your files get stored to, and checked out from when working in your workspace. Files stored here won’t be in their native format, and non-binary files will have their contents tweaked on top of that. Depot directory trees can be manually copied/paste to a backup location.
Proper backup/recovery information can be found here. Like many things, it’s simple once you understand it, but reading this is a bit of a mouth full. It would have helped me to just see slightly fleshed out sample commands along with the reading material, so I’ve included some here. These are the bare minimum command line commands (plus other manual stuff), and will recover a checkpoint, not checkpoint + journal (again, take a look at the link to get a better understanding). Also, I would recommend practicing backup/recovery in a safe throw away environment (or throw away assets) to get the hang of this before doing it for real.
---------- Backup ------------
Despite all the material in the link, it only takes a bare minimum of 3 command line commands (plus other non-command stuff) to do a proper P4 backup, and 1 cmd (among other things) to recover on my end. Again this is only a partially fleshed out sample to illustrate what the command prompt portion of backup/recovery looks like. There is a little more to it than simply running these to get you where you want.
(note: On Windows, you may need to start a windows command prompt as administrator)
>p4 set P4USER=superuser_name
>p4 -q verify //...
>p4d -r "C:\Program Files\Perforce\Server" -jc <yourBackupDirectory>\<prefixOfYourChoosing>
---------- Recovery ------------
>p4d -f -r "C:\Program Files\Perforce\Server" -jr <yourBackupDirectory>\<prefixYouChose>.ckp.1
In my case, I had to use the -f flag due to errors when not using it.
Cheers,
Paul W
I'm a very fresh user of Perfoce, so please be patient!
I am trying to create a commit (I understand it that in Perforce it is called a changelist) of the files which have been changed. It sort of happens automatically in other VC systems, but there seems to be no easy way of doing it in p4... The problem is (maybe) that I'm not editing the files by hand, the files are generated (please don't ask me why do I have to check in the generated files...) so the whole directory tree is getting removed and then copied over with the new files. But Perforce acts as if nothing happened. In both my workspace and the depot it displays the updated files, but when someone will check them out on another machine, the files will be of the previous version.
I'm fine with doing it either through GUI or through the command line. I'd prefer the command line, because that would spare me the trouble in the long run, but it doesn't seem like it should be much hassle either way.
In other words, let's say, this is the workflow I'm used to from SVN or Git:
Run status to see what changed.
Stage / add to commit what you want to be in the next revision.
Commit and send it to the versioning server.
What I'm not able to do is the "stage" phase - because the changes are not discovered automatically.
EDIT
Ah, I think, I figured it out: reconciliation was what I needed... well, I guess if you don't marry, this word would hardly ever happen in your vocabulary :)
It appears that the proper command is reconcile. Also, as Bryan Pendleton suggested there should be status, but I must have an older version of Perforces, which doesn't have this command. This command is also available from context menu in either depot or workspace panels of Perforce graphical interface, when you click on the modified file.
Using P4V 2009.2.
I have used P4Win in the past, but this is a new setup for me.
The problem is that the files I have checked out disappear from the changelists, so I cannot check them in.
To reproduce:
Check out a file, make a change to it.
Go to the 'pending changelist' tab.
There will be a + sign on the default changelist.
Click on the plus, or on the changelist line, the plus will disappear, there will be nothing in the changelist.
Try to check the file in by right-click on the file itself, the changelist dialog will show up but NO files are listed.
You can transfer the file to a new changelist, the same thing happens.
Looking at the file in the 'checked out by' window does correctly show the changelist number & description.
It sometimes happens to me, and what I normally do is change workspace and then change back again. Not sure if there is an easier way to get it to realise the files are checked out.
the only thing I can imagine is that you are looking at a different client workspace. Notice that the "Pending Changes" tab has a filter on the top, where you can separately filter for folder/files, user and workspace. Maybe the filter is set to something so that it doesn't match the client workspace where you have actually checked out the file.
Good luck,
Henrik
You may get this if the perforce server has not been upgraded. Old versions of P4D have this error: http://kb.perforce.com/article/1167/opened-files-missing-in-default-changelist
If that is not an option, use p4Win.
I agree with jhwist,sounds like your looking at a different client spec.
P4V is a bit confusing on this front, IMO and I personally prefer P4 Win but to check, open up a command prompt and type p4 changes -s pending -c YOURCLIENTSPEC - chances are that the changes you think you have aren't in your current clientspec
This can happen sometimes and in my experience it is a refresh issue with p4v. Often simply closing the pending tab or reopening p4v solves the problem.
In my case, the pending List has over 4000 files, (due to eclipse created so many files after mvn tasks) so none of them are shown. I created a different pending list, then cleared all contents, then moved the files to the new change list. Then it is appearing in the new change list.
Modify the file directly in the correctly mapped client folder (i.e. your current workspace). You will see the changelist for sure. As jhwist mentioned clear filters if any and choose your current workspace (since you may have many)
Can I rename a folder in Perforce from //depot/FooBar/ to //depot/Foobar/?
I've tried this by renaming from //depot/FooBar/ to //depot/Temp/ to //Depot/Foobar/ but the end result ends up the same as //depot/FooBar/.
Once it is in Perforce, the case remains set. As mentioned by Johan you can obliterate, set the name up correctly, and add it in again. However, there is a slight gotcha....
If anyone else (running Windows) has already synced the wrong-cased version, then when they sync again the right one, it will not change the case on their PC. This is a peculiarity of the Windows file system acknowledging case but still being fundamentally case-independent.
If a number of users have synced, and it is not convenient to get them to remove-from-client too (and blasting the folders from their machines), then you can resort to a dark and dirty Perforce technique called "Checkpoint surgery". It's not for the fainthearted, but you do this:
Stop your server, take a checkpoint.
Using your favourite text editor that can handle multi-megabyte files, search & replace all occurances of the old case name with the new. You could of course use a script too.
Replay your checkpoint file to recreate the Perforce database meta data.
Restart your server.
This will affect all user client specs transparently, and so when they sync they will get the right case as if by magic.
It sounds hairy, but I've had to do it before and as long as you take care, backup, do a trial run etc, then all should be OK.
Maybe not needed anymore, but here's the official Perforce HowTo about changing file cases on Windows and Unix: http://answers.perforce.com/articles/KB/3448/?q=change+file+case
I'm not sure about directories, but we've had this problem with files. To fix it, we have to delete the file, submit that change, then p4 add the file with the correct case and submit the second change. Once that's done, unix users who have sync'ed the incorrect-case file have to p4 sync, then physically delete the file (because p4 won't update the case) and then p4 sync -f the file.
Our server is on Windows, so that might make a difference.
I guess it treats files and folders the same.
For files:
It depends (on whether you have a Windows or Unix server). We have this problem with our Windows perforce server (which versions our Java code), where very occasionally someone will check in a file with a case problem (this then causes compile errors because it's Java). The only way to fix this is to obliterate the file and resubmit it with the correct case.
I think you should remove the Perforce Cache, so that your modification can be shown.
You can rename with ABC rename to abc_TMP, then abc_TMP rename to abc, then clear cache.
Setps to clear cache:
Open windows user home folder (on windows7 ==> C:\Users\)
Locate the folder called ".p4qt"
Rename the folder to "old.p4qt"
Launch Perforce, now everything works!
NOTE: these steps will rest your default setting.
The question is over 3 years old, but I ran into an issue like this while doing a Subversion import into Perforce and figured the info I got could be useful to some. It's similar to the obliterate method, but helps you retain history. You use the duplicate command that may not have been available back then to retain the history. The process basically being:
Duplicate to temporary location.
Obliterate the location you just duplicated.
Duplicate from the temporary location to the renamed case location.
Obliterate the temporary location.
Through this you retain the history of file changes, but get them all in the new path as well. Unfortunately there will be no history of the path case change, but that seems to be unavoidable. Similar to other methods mentioned here, users will need to either manually rename the directories in their workspace or delete and re-sync to get the new path name.
Also, P4V caches the paths it shows in the tree so after doing this it may still show up as the old name. a p4 dirs command however will show the new case.