Some more notes on pristines-mode configuration.
Naming of option values: agreed that we need to choose names carefully,
avoiding ambiguity like 'mode=all'.
On the consensus that:
(1) There should be a user config (file/registry/cmdline) option to set
the desired pristines-mode that will be applied to a new/upgraded WC on
checkout/upgrade.
(2) The desired pristines-mode should be persisted as a property of
the working copy, stored in the WC.
(1) Once we implement a user config setting, then there automatically is
a cmdline option:
- svn co --config-option=config:working-copy:pristines-mode=FOO
It would of course be nice to have an abbreviation, such as one of:
- svn co --wc-option=pristines-mode=FOO
- svn co --pristines-mode=FOO
I suggest such abbreviation is a nicety to be added if we have the time
and inclination, otherwise no big deal to leave it out.
(2) The in-WC setting could be stored either as:
(2a) a user-editable setting in (new invention) a 'wc/.svn/config'
file; or
(2b) a machine-editable setting in wc.db; plus a command for changing
it later.
The former (2a, a wc config file) has the nice property of being plain
text user-editable and in the same format as '~/.subversion/config' and
'repo/conf/svnserve.conf'. No additional commands needed to change it.
Introducing a new config file is, strictly speaking, an orthogonal
change, and should be committed separately. The current patch in this
thread contains the basic implementation. Additional work:
- Document its existence. (Where?)
- Generate the file, containing documentation and commented-out
example settings, when creating a new WC.
For the latter (2b, setting in wc.db), we would need:
- some way to display it;
- a separate command to change it later.
These might be quite simple at the UI level, such as 'svn info' to
display it and 'svn checkout --force' to change it. Even a simple UI
change requires a non-negligible amount of code churn in the client and
WC layer APIs. I don't see any advantages ("performance"? "locality"?)
of storage in wc.db.
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?
Finally now, Lorenz brought up the idea of basing the mode setting on
wc-props, so the user could use (a variant of) the existing properties
mechanism for per-subdirectories and per-file control. That could turn
into a powerful, more general mechanism for configuring any
client-specific properties of a WC and its paths, not specific to
controlling pristines. However, that seems a substantial and tangential
design project, not something to tackle within pristines-on-demand. We
might like to explore it further as a side project.
- Julian
