> -----Original Message-----
> From: Greg Stein [mailto:gstein_at_gmail.com]
> Sent: woensdag 7 april 2010 23:25
> To: Philip Martin
> Cc: dev_at_subversion.apache.org
> Subject: Re: fourth tree: "INHERITED" (was: wc-ng base/working nodes in
> a copied tree)
>
> After some further discussion on IRC, and some thought...
>
> I think this may be more of a representational problem, and might not
> be a "true" fourth tree. Especially because supporting the revert
> scenario actually implies N trees. Bert tried to describe this a while
> back, but I didn't understand his description (too many "A" nodes).
> Consider the following:
>
> $ svn cp A X # copies A/Y/Z/file
> $ svn cp B X/Y # copies B/Z/file
> $ svn cp C X/Y/Z # copies C/file
> $ svn cp file X/Y/Z/file
>
> We have four operation roots, and four layers of "file". Reverting
> each op-root will reveal the previous layer.
>
> In 1.6, we probably had just one layer, but if we're going to solve
> this, then let's do it right.
>
> I propose that we create a new table called NODE_DATA which is keyed
> by <wc_id, local_relpath, op_depth>. The first two are the usual, and
> op_depth is the "operation depth". In the above example, we have four
> WORKING_NODE rows, each establishing an operation root, with
> local_relpath values of [X, X/Y, X/Y/Z, X/Y/Z/file]. In the NODE_DATA
> table, we have the following four rows:
>
> <1, X/Y/Z/file, 1> # from the X op-root
> <1, X/Y/Z/file, 2> # from the X/Y op-root
> <1, X/Y/Z/file, 3> # from the X/Y/Z op-root
> <1, X/Y/Z/file, 4> # from the X/Y/Z/file op-root
>
> Essentially, op_depth = oproot_relpath.count('/') + 1
>
> We can record BASE node data as op_depth == 0.
>
> Looking up the data for "file" is a query like this:
>
> SELECT * from NODE_DATA
> WHERE wc_id = ?1 AND local_relpath = ?2
> ORDER BY op_depth DESC
> LIMIT 1;
>
> That provides the "current" file data.
>
> Some of the common columns between BASE_NODE and WORKING_NODE move to
> this new NODE_DATA table. I think they are:
>
> kind, [checksum], changed_*, properties
I think you need some kind of 'not-present'/'excluded' status in this
copied/inherited/fourth tree too.
If you have a working copy
/A
/A/B
/A/B/C
Where you exclude C
/A
/A/B
[/A/B/C] (excluded)
Then you make a copy of /A to /D
/A
[/A/B/C] (excluded)
/D (copy)
/D/B (child of copy)
[/D/B/C] (excluded child of copy)
And then we delete /D/B
/A
/A/B[/C]
/D (copy)
/D/B (deleted)
Then I want to revert the delete of /D/B.
/A
/A/B[/C]
/D (copy)
/D/B (child of copy)
Note that there is no:
[/D/B/C] (excluded child of copy)
The new COPIED table allows me to get all the information on B back, but I
miss the information that it once had a child C that was excluded.
So if I commit the tree I get a working copy that assumes that I still have
/D/B/C, because nothing recorded that I don't have that node locally.
Bert
Received on 2010-04-07 23:47:00 CEST