The encoding defined in the P4Merge Preferences is the one used when you launch it. You can then change the encoding for the current session by selecting the menu File->Character Encoding.
If you're launching P4Merge from P4V, P4V passes its current encoding to P4Merge, overriding its preferences.
The only workaround would be to define P4Merge as a 3rd party Diff/Merge tool in P4V Preferences. Then the P4Merge encoding preference you set will be used.
Hope this helps
Hi, thanks for the reply, we have tried to set in p4merge preferences, but it looks like not working.
When I start P4Merge by diff files, the encoding is "System" by default, but I already set it to "utf8 no bom" in the preference (our system encoding is not utf8) 1234.png21.93K7 downloads
Yes, the size of the db files is a much better gauge for how long the checkpoint will take!
If you want to try to gauge how close the checkpoint is to completion, you can peek at the checkpoint file and see which tables have been dumped so far. The tables will be checkpointed in the locking order (documented here: https://www.perforce...current/schema/) and the number of rows in each table will roughly correspond to their size on disk. Typically db.have, db.rev, and db.integed are the largest ones.
The time to create a checkpoint isn't necessarily a function of the size of the journal file; most of what's in the journal won't end up in the checkpoint (e.g. db.have entries that have since been overwritten).
Since a checkpoint is primarily a read operation, it should be safe to kill it without damaging the db, but the checkpoint it's writing will be incomplete and is not suitable for recovery, and the journal will not be rotated. The next time you take a checkpoint it'll start over from the beginning.
thank you! so it's safety to break the process, that's a good news!
from your answer, can I say that size of db files will affect the time spent on creating checkpoint? The db files save records from journal, and the checkpoint read records from db files, is this the workflow?
It depends on the tool. If it's running a simple p4 command, you don't need any API beyond the CLI tool. If it's something more complex but nothing graphical, I'd write a Python script using P4Python. If it's a graphical tool where I needed to use Cocoa, I'd write it in Obj C (ugh) and use the C++ API.
thanks a lot, I will develop a graphical tool with you suggestion