Hey all,
In short: Julian was right. He just couldn't explain/justify why :-)
Longer answer:
Today, we have been looking at the WC as comprised of three trees,
each holding the following information:
BASE (the pristine stuff we got from the server)
contains: directory structure, file contents, properties
WORKING (changes made in WC (administratively))
contains: directory structure, properties
ACTUAL (edits or non-svn changes)
contains: directory structure, file contents
Above is both the model, and a reflection of how we store/manage the
various trees. Julian argued that all the trees should contain all
three items, but since *empirically* we built the code as above, it
was hard to justify why that was nothing more than being pedantic.
That we didn't need to look at the trees as all fully-formed.
However, we *do* have code for all parts, for all three trees. It was
just hard to *see* because it kind of falls under different names.
So. First, let's just say that "svn propset" and friends modify
properties in the ACTUAL tree, and ignore the fact that they're stored
in administrative bits. Or that you can't really use non-svn commands
to modify them. That shifts the properties down from WORKING into
ACTUAL. So now WORKING just has "directory structure", as modified by
things like "svn add/delete/copy/move". Let's now add file contents
and properties to WORKING, with the understanding that they are
*usually* the same as the values in BASE.
Now think about what happens when a file or tree is in "replaced"
state. The file contents in WORKING need to correspond to the *new*
node's pristine text. In the current code, we call that the "revert
base". Same applies to "revert properties".
The file contents in WORKING are part of the crazy code we have right
now. If you add with history, then we store the contents as if they
were part of BASE. But if there *was* a base (the add is replacing),
then only in that case do we switch to storing as the "revert base".
This flow of concepts and storage between the BASE and WORKING trees
is one of the things making the code all wonky.
So with this new realization, I think it will be important to revisit
the wc_db.h APIs and the SQL schema. Make sure that we can properly
model the three trees and how they get used and stored. I'm still
messing with some temp file stuff and path assumptions in the code, so
I'm not worrying about it just yet. Will probably be important for
hwright's properties work though.
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=981387
Received on 2008-12-09 01:24:32 CET