Is there a way to recover a perforce depot where you only have the version files? The server where perforce was running on has crashed and is not currently running. Can I recovery from this?
Thanks in Advance
This is extremely hard and generally impossible, because critical information is stored in the Perforce server's database tables, which are separate from the version files.
But why not restart the Perforce server? Why did it crash, and why is it not currently running?
It sounds like you need to get in touch with Perforce Technical Support.
Related
I have this situation: I have many files on my HD that come from an old perforce server. The new server has the same files, but the "have list" is not up to date, and according to it I have no files.
The server is not 100% like my HD, so if I run "p4 flush" I'll break it, because many files that are not in my HD but are in the server will be marked as "have" and will not be synced later.
Is there a way to sync the have list exactly to what you have in your client?
Thanks very much for you help!
Alex
Start with a p4 flush to your best guess, and then do p4 clean to force-sync everything that doesn't match.
In my company we're using a perforce and last time we started to receive "The filesystem 'P4LOG' has only XXX free, but the server configuration requires at least YYY available". What does it means. I tried to google and all I found is that this is env variable - Name and path of the file to which Perforce errors are written. We asked our administrator to fix the problem and he increased min file size, that removes an error for some time but later it appears again. Why this warning appears? How to prevent it?
Your administrator can either set up Perforce's specific log rotation tool, or use the standard Linux logrotate tool. This is essential if you don't want to keep running out of disk space on the Perforce server.
As the p4 logrotate docs mention, p4 logrotate happens automatically on a checkpointing or journaling event. You should have checkpointing and journaling set up so that you don't run the risk of losing your entire depot if the p4 server has a problem.
Your administrator needs to let up log rotation. Log rotation will compress recent logs and remove old ones.
I have an issue related to how to incremental backup MySQL workbench.
Can anyone tell me the script to backup this?
I want to back up all day and keep incremental with difference file.
Can anyone give me the sample script about that?
Thank,
Veasna.
The binary log (mysql-bin.log) is essentially an incremental back-up. It allows you to revert back to a previously stable database state.
see http://dev.mysql.com/doc/mysql-backup-excerpt/5.0/en/backup-policy.html
Making Incremental Backups by Enabling the Binary Log,
http://dev.mysql.com/doc/refman/5.6/en/backup-methods.html
May i know from where you are restarting the service, through command prompt Or from your control panel.
Share your error message here, you Will get further details if anyone knows.
I did a migration of the perforce server. Because there are many depots and many data and because our department does not want that the server is down for a day, I did the following:
Step 2 : Stop the 'old' perforce server on machine A
Step 1 : Copy all data from machine A to machine B
Step 2 : Start again the 'old' server
Setp 3 : Do the complete migration and start the new server at machine B
Now the problem is that in the meanwile, there are several changelists submitted to machine A.
Is there an easy way to copy the changes to machine B ? Note that I have a checkpoint, so the metadata is not the problem.
I know that on version controls like git it is easy with patches. Is such a thing also possible in perforce in an easy way?
You may want to look at p4 pull and p4 replicate command given by perforce.
P4 Pull and P4 Replicate are the 2 commands given for purpose like these. I am assuming that your p4 server is p4d 2010.2 or above for these commands.
Also, I would recommend you reading Perforce's knowledge base for their article on Offline check pointing. This article is not a direct solution to your problem, but it gives you insight of how you may tackle your situation.
Hope this helps.
Did you truncate your journal when you did the first migration? If so, you can probably replay the latest production journal and then rsync/robocopy the archive content (files in the depots). That'll let you catch up.
I assume this is a one-off activity?
You should probably check in with Perforce tech support just to make sure you're not overlooking anything.
I have to regularly do a clean Perforce sync to new hardware/virtual machines over the VPN. This can take hours as the project is quite large. Is there a way that I can simply copy an up-to-date tree from an existing client and tell Perforce to use this tree?
The Perforce Proxy is the right way to go, but if you really want to, there is a way to do what you asked via the sync command, with the -k switch:
The -k flag bypasses the client file
update. It can be used to make the
server believe that a client workspace
already has the file. Typically this
flag is used to correct the Perforce
server when it is wrong about what
files are on the client, use of this
option can confuse the server if you
are wrong about the client's contents.
p4 sync -k //depot/someProject/...
You can also use flush, which is a synonym for sync -k:
p4 flush //depot/someProject/...
Just be careful. Remember those last words, "...use of this option can confuse the server if you are wrong about the client's contents."
Perforce Proxy is almost definitely the way to go, assuming you can dedicate a local machine for this purpose.
A useful tip for a Proxy is to get it to refresh its contents overnight, just by creating a dummy client (perhaps on the proxy machine), and kicking off a nightly task to do a sync - a normal sync will do, does not need to be a clean one. This will ensure any big changes people have checked in won't necessarily cause a massive lag the first time you need to do a local sync.
Note that you need a live VPN connection between the proxy and the server - the proxy still has to talk to the server to determine if it has the right versions cached. So the proxy needs a reasonably low latency link to the server, but at least you don't have to wait for actual file transfer.
Another alternative you may want to try is to use the compress option in your client specs (workspaces). This tells the server to compress each file before it gets sent, and your p4 client will decompress automatically. The trade-off here is CPU time on both the server and the client. However, given you want to sync several local clients, I think proxy will ultimately be the better solution.
No, but you shouldn't need to: Why do you need to do a clean perforce sync? What's wrong with a normal sync? If you need to clean the tree, then why not work on a copy of the tree?
One alternative might be to run a p4proxy on your end of the VPN connection, then unchanged files won't have to be transferred over the VPN.
If you only require an export - that is you don't need to keep it up-to-date or submit changes from it, then you could simply copy an existing checkout, and never use perforce against that tree. But I don't know anyway of convincing perforce server that you have a checkout without p4 actually checking out the files.