[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: NODE_DATA (aka fourth tree)

From: Greg Stein <gstein_at_gmail.com>
Date: Sat, 10 Jul 2010 19:04:04 -0400

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

> 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.


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 !=

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.

Received on 2010-07-11 01:04:45 CEST

This is an archived mail posted to the Subversion Dev mailing list.