On Sat, Jul 10, 2010 at 17:55, Erik Huelsmann <ehuels_at_gmail.com> wrote:
>...
> Columns to be placed in NODE_DATA:
>
> * wc_id
> * local_relpath
> * oproot_distance
> * presence
> * kind
> * revnum
revnum is a BASE concept, so it does not belong here. WORKING nodes do
not have a revision until they are committed. If the node is copied
from the repository, then the *source* of that copy needs a revision
and path, but that is conceptually different from "revnum" (which
identifies the rev of the node itself).
> * checksum
> * translated_size
> * last_mod_time
> * changed_rev
> * changed_date
> * changed_author
> * depth
> * properties
> * dav_cache
dav_cache is also a BASE concept, and remains in BASE_NODE.
> * symlink_target
> * file_external
I'm not sure that file_external belongs here. We certainly don't have
it in WORKING_NODE.
> 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.
Right.
Also note that we can opportunistically rename the above columns to
their wc_db API names: original_*. They would be original_repos_id,
original_repos_relpath, original_revision.
(we can also rename BASE_NODE.revnum to BASE_NODE.revision)
>...
> 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.
Right now, we support copying a mixed-revision tree. During the copy,
we synthesize new oproots at each point where revision !=
parent_revision.
The real problem comes in with a local-add underneath a
copy/move-here. Adds do not have a marker to state "I'm not part of
the ancestor operation." We also have problems reverting child
operations, such as replacing a child of a copy/move-here. 1.6 is
apparently able to revert the replacement, returning the node to a
copied child. (maybe; there is *some* revert operation that 1.6 can do
that our current schema cannot accomplish; Philip may recall it)
So. In order to support that 1.6 revert scenario, and to better
support future revert capabilities, the NODE_DATA concept is needed.
It also solves the local-add under a copy problem.
Cheers,
-g
Received on 2010-07-11 01:04:45 CEST