Re: [p4] Partitioned vs readonly clients
Sambwise <[email protected]>
| Newsgroups | gmane.comp.version-control.perforce |
|---|---|
| Message-ID | <[email protected]> |
Posted on behalf of forum user 'Sambwise'. The relnotes are pretty terse: #1389236 (Bug #81369) ** A new 'partitioned' client type has been added. Like the 'readonly' type clients of this type have their own db.have tables that aren't journalled; however, these clients do allow files to be opened and submitted. Existing 'readonly' clients can be convtered to 'partitioned' by updating the 'Type' field. The question I'd have about partitioned clients is what the deal is with tables that track working state (db.working, db.locks, db.resolve). Do those get their own partitioned versions? The other question would be whether there are any special optimizations for read-only clients that you lose when you move to "partitioned", or if the benefit of readonly vs partitioned is solely to help guard against "accidentally" opening files in an unjournalled client. I'm guessing that if you have any work in progress on a partitioned client and you need to do a journal recovery there's a bit of pain involved to reconstruct a consistent state, vs a "readonly" client where since it's guaranteed that no files were open you can always just do a flush+clean and everything is fine. -- Please click here to see the post in its original format: http://forums.perforce.com/index.php?/topic/5531-partitioned-vs-readonly-clients _______________________________________________ perforce-user mailing list - [email protected] http://maillist.perforce.com/mailman/listinfo/perforce-user