Pre-Design Discussion of Server->client configuration

I was happy that Karl suggested dealing with issue #1974 and friends as
part of the push for 1.3, especially if the design lends itself
to "custom keywords" and possibly the "inherited properties" feature.

As an introduction to that, I thought I'd document some hard-won
knowledge of how the WC code is structured (barring a rewrite of course)
at a very high level. Specifically, I'm going to mostly describe how
keywords work, but I think the behaviors are transferable to
server-resident config issues. I'm sure the more experienced developers
already "know" this, but I want to lay it out so everyone is aware of
the limitations.

1) Subversion is intended to work offline most of the time - by this I
mean that the WC is intended to be largely independent of any
communication with the server except for specific operations that
require it. In terms of keyword expansion, this means that the only
information which can be used to expand keywords must be available in
the working copy files. In particular, it must always be possible to
`svn revert` at any time and recreate the file(s) using only the
information present in the WC itself.

2) The WC is completely modular - by this I mean that any subtree of a
checked out WC can be treated as a firstclass WC in its own right
(including moving the subtree in the filesystem). What this means is
that there is no "top level" or "root" of a working copy. All of the WC
code basically works on the files in a single directory at a time and
then, any subdirectories are recursively handled (unless forbidden with -N).

3) The recursive nature of the WC means that every subtree must have
_all_ of the information available all the time. This either means that
things like inherited properties or server config files have to be
stored either in the WC admin files in each and every subtree or they
have to be stored in some common space outside of the WC tree entirely
(like the .subversion directory). Common config files could be stored
in a hash by UUID in the .subversion directory for caching purposes, but
it would mean that deleting a WC would not remove this information from
the disk (unless a new 'svn release' command were added).

4) Any custom config information (whether talking about server config
overrides or custom keywords) has to be available to the client code
/before/ it begins communicating with the server. In the case of custom
keywords, the working copy file needs to unexpand the changed files
before sending the changes to the server. Similarly, in the case of a
custom log message template, the client code needs that to generate the
log message before sending the commit. Consequently, the
server-mediated config files must be stored locally to the client and
need to be versioned (so the server can see if the client has the most
recent revision, just like the out-of-date check for commits).

I don't know if this is in any way helpful; each of the above is largely
a variation on the same theme.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org