Julian Foad <julianf...@apache.org> writes: > Some people said it should be in wc.db. Evgeny wrote, "this sounds like > a property associated with a specificwc_id in the database. I would say > that this pretty much rules out optionsof storing it outside the wc.db." > But (Brane wrote) "WC_ID is hardcoded to 1 pretty much everywhere." > > What do you all make of this now? Is a new WC config file plausible?
I tend to think that using a per-wc config file could potentially introduce more problems that it solves. A few examples: - Even if WC_ID is currently hardcoded to 1, I think that storing the new property without associating it with a WC_ID would probably circumvent this part of the working copy design. In other words, if at some point the database starts to use more than one WC_ID, we would probably have to do something about a config option that works on a per-WC_ID basis but isn't persisted as such. - A user-editable config option implies that it can be changed externally and that the working copy has to cope with such a possibility. This rules out a relatively simple approach where the property is set when a working copy is created and is kept immutable afterwards. (This approach also allows entirely skipping the textbase sync by seeing that the stored pristines-on-demand property is false. Compared to that, the approach with a config option implies having to do a more thorough check because some of the pristines might be missing.) - To change this option programmatically, one would have to update an existing config file, which could be a non-trivial technical task, considering things like persisting comments and whitespace trivia. Thanks, Evgeny Kotkov (On vacation for a couple of weeks, so might not be able to respond promptly.)
