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

RE: fourth tree: "INHERITED" (was: wc-ng base/working nodes in a copied tree)

From: Bert Huijben <bert_at_qqmail.nl>
Date: Wed, 7 Apr 2010 23:46:19 +0200

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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.