Retrieve some Last Sync identifier
Posted 26 March 2020 - 05:45 PM
Because we have to work using a VPN these days, some huge, but previously fast enough, P4 fstat queries could now be extremely slow for some users. (from 2s avg on a local network, to 400s for some people)
This fstat command output is stored locally in case our P4 server/network get down.
I was wondering if there is any ways to retrieve from the server, a kind of MD5 or whatever representing the actual client synchronization status, for a specific filepath, or client wide, or anything else...
The only thing I see to achieve this would be to use command have on desired filepaths, compute a hash from its output, and compare it to the last computed one stored locally. But the output is already big enough to be problematic.
Do you know a way to obtain this kind of information from the server side ?
Maybe there's a far more simpler answer to my problem too.
Posted 27 March 2020 - 07:50 AM
Maybe I'm wrong but p4 cstat gives me the changelists containing files for which I'm not sync to the head (and for specific filepaths).
What I need is a kind of checksum of what a client has locally (in fact, what the server think he has), not a delta from the head.
Posted 27 March 2020 - 02:58 PM
Knowing that you're fully synced to all changelists up thru X implies that you're synced to all of those files, so that you can recreate the entire client state simply by saying "p4 sync @X" instead of individually syncing each of a million files to a particular individual revision. Instead of a have list that's millions of files long, you can potentially capture a client's entire state in a single integer (well, two if you count the version of the client spec in the spec depot).
Of course this doesn't account for "partial" changes. If you wanted to make a robust "client hashing" scheme you could use "cstat" for the easy wins and then use a command like "p4 sync @=CHANGE" for each partial change to capture the delta between the have list and those changes; then hash that up along with the "fully synced" changes and the client view. Ideally, most clients tend to be fully synced to particular changelists (tightly scoped client views and/or tightly scoped changes make this highly likely; conveniently both of these are baked into the streams data model, so if you're using streams you're probably set), and you won't have to deal with very many "partial" changes in practice.
Posted 28 March 2020 - 06:21 AM
I have to do some checks to see how large would be the output for my usage, but this is great.
Thanks a lot for the intel !
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users