As announced by gstein before, we've had some discussion on the
NODE_DATA structure which should allow storing multiple levels of tree
manipulation in our wc-db. This mail aims at describing my progress on
the subject so far. Please review and comment.
Introduction
----------------
What's the 4th tree about? The 4th tree is not 1 tree, but instead
it's the ability to store overlapping tree changes in our WORKING
tree. Take the following tree:
root
+- A - C - file
\- B - C - file
Then, imagine replacing A with B. All would be fine with our current
single level WORKING representation. However, if we replace 'file' in
the copied tree, a single level won't do anymore: if you revert the
replacement of file, you want to revert to what was there when the
tree was copied. The other option - which you don't want because it
would result in an inconsistent tree - would be that wc-ng would
revert to what was there even before the copy operation.
Being able to revert the 'file' replacement independently of the 'A'
replacement, you need 2 levels of WORKING nodes for 'file': one for
the direct replacement and one for the replacement that comes with
replacing 'A'. Using the same logic, many levels may be required to
model complicated working copy changes.
What this change is not
----------------------------------
This change does not include any change to the current behaviour of
libsvn_wc that modifying modified trees are destructive operations.
The multi-level model exists only to keep track of WORKING tree
changes, not to make changes to the ACTUAL tree visible again after
reverting a replaced subtree.
Proposed change
-------------------------
Greg made a proposal on the list some time ago which allows the
required multiplicity of WORKING nodes by creating a new table:
NODE_DATA. The table was proposed to hold a subset of the columns
currently in the BASE_NODE and WORKING_NODE tables.
The rationale about storing the BASE_NODE data in the table too is
that a query for a node which doesn't have a WORKING version will
simply return the BASE version. That way, there's no need to teach the
code about the absense of WORKING. Although the BASE_NODE information
is put in this table, this doesn't mean the BASE_NODE and WORKING_NODE
concepts are being redefined, other than allowing layered WORKING_NODE
(sub)trees.
Columns to be placed in NODE_DATA:
* wc_id
* local_relpath
* oproot_distance
* presence
* kind
* revnum
* checksum
* translated_size
* last_mod_time
* changed_rev
* changed_date
* changed_author
* depth
* properties
* dav_cache
* symlink_target
* file_external
This means, these columns stay in WORKING_NODE (next to its key, ofcourse):
* copyfrom_repos_id
* copyfrom_repos_path
* copyfrom_revnum
* moved_here
* moved_to
These columns can stay in WORKING_NODE, because all children inherit
their values from the oproot. I.e. a subdirectory of a copied
directory inherits the copy/move info, unless it's been copied/moved
itself, in which case it has its own copy information.
As described before, sorting the nodes relating to a certain path in
ascending order relating to their oproot, you'd always get the
'current' WORKING state applicable to the node, if the distance
between the node and the working copy root is used to identify the
BASE_NODE data.
Most -if not all- of the changes to the underlying table structure
should stay hidden behind the wc-db API.
Relevance to 1.7
----------------------
Why do we need this change now? Why can't it wait until we finished
1.7, after all, it's just polishing the way we versioned directories
in wc-1, right?
Not exactly. Currently, mixed-revision working copies are modelled
using an oproot for each subtree with its own revision number. That
means that without this change, effectively we can't represent
mixed-revision working copy trees. So, in order to achieve feature
parity with 1.6, we need to realise this change before 1.7.
Well, that's basically it. Comments?
Bye,
Erik.
Received on 2010-07-10 23:56:15 CEST