[RFC] Comments on wc-metadata.sql PRISTINE and

[Julian Foad <ju...@wandisco.com>]

Hey WC-NG folks, please tell me what's right/wrong/unsure in the
additions and changes below. Feel free to commit any parts that are
right: I'm not yet familiar enough to really be comfortable committing
it myself but I will if you want.

- Julian

Re: [RFC] Comments on wc-metadata.sql PRISTINE and

[Julian Foad <ju...@wandisco.com>]

Neels J Hofmeyr wrote:
> Julian Foad wrote:
> > +   Every path for which an entry exists in the WORKING_NODE table also    has
> > +   an entry in the BASE_NODE table.
> 
> AFAIR, this is not true for locally added nodes. Am I right?

Correct. Greg pointed it out and I fixed the comment in r911380. Thanks.

- Julian

Re: [RFC] Comments on wc-metadata.sql PRISTINE and

[Neels J Hofmeyr <ne...@elego.de>]

Julian Foad wrote:
> Hey WC-NG folks, please tell me what's right/wrong/unsure in the
> additions and changes below. Feel free to commit any parts that are
> right: I'm not yet familiar enough to really be comfortable committing
> it myself but I will if you want.
> 
> - Julian
> 
> 

> +   Every path for which an entry exists in the WORKING_NODE table also    has
> +   an entry in the BASE_NODE table.

AFAIR, this is not true for locally added nodes. Am I right?

~Neels

Re: [RFC] Comments on wc-metadata.sql PRISTINE and

[Julian Foad <ju...@wandisco.com>]

On Wed, 2010-02-17, Greg Stein wrote:
> Also: PRISTINE.size is the size on-disk, which may be different from
> the uncompressed size.

Committed revision 911317.

> The on-disk size is handier than the uncompressed size, I believe.

Dunno, but let's start where we are.

- Julian

Re: [RFC] Comments on wc-metadata.sql PRISTINE and - translated size

[Julian Foad <ju...@wandisco.com>]

On Wed, 2010-02-17, Greg Stein wrote:
> To further illuminate here... the *same* pristine could have variant
> translated_size values based on each node's set of properties
> (svn:keywords, svn:eol-style, etc). That is why we attached the
> translated_size to the BASE_NODE and WORKING_NODE tables. A/foo and
> A/bar could use the same pristine, but have different on-disk
> representations due to the properties attached to each.
> 
> Hunh. Now that I think about it, if you change the properties on a
> node (ie. new props go into ACTUAL_NODE), then we do not have a
> modified translated_size. Darn it. I think we're going to need to add
> that...

Whether we need this depends on whether we want to translate a pristine
text according to the *working* props or only ever according to the
*pristine* props.

- Julian

Re: [RFC] Comments on wc-metadata.sql PRISTINE and

[Greg Stein <gs...@gmail.com>]

On Wed, Feb 17, 2010 at 14:14, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On Wed, Feb 17, 2010 at 10:12 PM, Greg Stein <gs...@gmail.com> wrote:
>> On Wed, Feb 17, 2010 at 14:03, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>> On Wed, Feb 17, 2010 at 9:57 PM, Greg Stein <gs...@gmail.com> wrote:
>>>> Also: PRISTINE.size is the size on-disk, which may be different from
>>>> the uncompressed size.
>>>>
>>>> The on-disk size is handier than the uncompressed size, I believe.
>>>>
>>> Just one note from wc-1 experience: It's good to have translated
>>> pristine size to quickly answer that file modified without comparison
>>> file contents at all.
>>
>> That value is stored in BASE_NODE and WORKING_NODE as the column
>> 'translated_size'. The size needs to account for EOL and keyword
>> translations.
>>
> Great, I didn't aware about this.

No problem.

To further illuminate here... the *same* pristine could have variant
translated_size values based on each node's set of properties
(svn:keywords, svn:eol-style, etc). That is why we attached the
translated_size to the BASE_NODE and WORKING_NODE tables. A/foo and
A/bar could use the same pristine, but have different on-disk
representations due to the properties attached to each.

Hunh. Now that I think about it, if you change the properties on a
node (ie. new props go into ACTUAL_NODE), then we do not have a
modified translated_size. Darn it. I think we're going to need to add
that...

Cheers,
-g

Re: [RFC] Comments on wc-metadata.sql PRISTINE and

[Ivan Zhakov <iv...@visualsvn.com>]

On Wed, Feb 17, 2010 at 10:12 PM, Greg Stein <gs...@gmail.com> wrote:
> On Wed, Feb 17, 2010 at 14:03, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> On Wed, Feb 17, 2010 at 9:57 PM, Greg Stein <gs...@gmail.com> wrote:
>>> Also: PRISTINE.size is the size on-disk, which may be different from
>>> the uncompressed size.
>>>
>>> The on-disk size is handier than the uncompressed size, I believe.
>>>
>> Just one note from wc-1 experience: It's good to have translated
>> pristine size to quickly answer that file modified without comparison
>> file contents at all.
>
> That value is stored in BASE_NODE and WORKING_NODE as the column
> 'translated_size'. The size needs to account for EOL and keyword
> translations.
>
Great, I didn't aware about this.


-- 
Ivan Zhakov
VisualSVN Team

Re: [RFC] Comments on wc-metadata.sql PRISTINE and

[Greg Stein <gs...@gmail.com>]

On Wed, Feb 17, 2010 at 14:03, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On Wed, Feb 17, 2010 at 9:57 PM, Greg Stein <gs...@gmail.com> wrote:
>> Also: PRISTINE.size is the size on-disk, which may be different from
>> the uncompressed size.
>>
>> The on-disk size is handier than the uncompressed size, I believe.
>>
> Just one note from wc-1 experience: It's good to have translated
> pristine size to quickly answer that file modified without comparison
> file contents at all.

That value is stored in BASE_NODE and WORKING_NODE as the column
'translated_size'. The size needs to account for EOL and keyword
translations.

Cheers,
-g

Re: [RFC] Comments on wc-metadata.sql PRISTINE and

[Ivan Zhakov <iv...@visualsvn.com>]

On Wed, Feb 17, 2010 at 9:57 PM, Greg Stein <gs...@gmail.com> wrote:
> Also: PRISTINE.size is the size on-disk, which may be different from
> the uncompressed size.
>
> The on-disk size is handier than the uncompressed size, I believe.
>
Just one note from wc-1 experience: It's good to have translated
pristine size to quickly answer that file modified without comparison
file contents at all.


-- 
Ivan Zhakov
VisualSVN Team

Re: [RFC] Comments on wc-metadata.sql PRISTINE and

[Greg Stein <gs...@gmail.com>]

Also: PRISTINE.size is the size on-disk, which may be different from
the uncompressed size.

The on-disk size is handier than the uncompressed size, I believe.

On Wed, Feb 17, 2010 at 13:51, Greg Stein <gs...@gmail.com> wrote:
> WORKING_NODE rows exist for *all* affected nodes.
>
> ACTUAL_NODE rows may exist w/o a corresponding WORKING_NODE row (in
> which case, there better be a BASE_NODE row).
>
> In the comments, we should be better about stating null rather than
> NULL (as the latter indicates a NULL pointer, not the SQL null value).
>
> moved_here is 1 or something else. There is no need to have a tri-state.
>
> Your comment with respect to moved_to is incomplete. There are more
> possible states than just 'base-deleted' and 'normal'. You could also
> have (at least) 'not-present' on a child. Consider the sequence: MOVE
> A to B. COPY C to A. DELETE A/D. The A/D child will be not-present.
>
> Cheers,
> -g
>
> On Wed, Feb 17, 2010 at 13:38, Julian Foad <ju...@wandisco.com> wrote:
>> Hey WC-NG folks, please tell me what's right/wrong/unsure in the
>> additions and changes below. Feel free to commit any parts that are
>> right: I'm not yet familiar enough to really be comfortable committing
>> it myself but I will if you want.
>>
>> - Julian
>>
>>
>

Re: [RFC] Comments on wc-metadata.sql PRISTINE and

[Julian Foad <ju...@wandisco.com>]

Thanks, Greg.

On Wed, 2010-02-17, Greg Stein wrote:
> WORKING_NODE rows exist for *all* affected nodes.

Meaning all (grand)children of any affected directory as well, I take
it. OK, Bert confirmed on IRC. Fixed.

> ACTUAL_NODE rows may exist w/o a corresponding WORKING_NODE row (in
> which case, there better be a BASE_NODE row).

OK, fixed.

I added overall doc strings to each table in r911348, incorporating the
above fixes and making sure I say "table row" rather than "table entry".

> In the comments, we should be better about stating null rather than
> NULL (as the latter indicates a NULL pointer, not the SQL null value).

I suppose we could, but I think of "NULL" as indicating a
computer-language keyword and "null" as English prose, not one for C
code and the other for SQL. In the context of pure SQL documentation,
there is no ambiguity because there are no C pointers, but where C and
SQL co-exist (in C code) I think we'll have to employ more words rather
than letter case differences to distinguish them.

> moved_here is 1 or something else. There is no need to have a tri-state.

I'll leave it alone.

> Your comment with respect to moved_to is incomplete. There are more
> possible states than just 'base-deleted' and 'normal'. You could also
> have (at least) 'not-present' on a child. Consider the sequence: MOVE
> A to B. COPY C to A. DELETE A/D. The A/D child will be not-present.

OK, I'll just delete the attempt to explain that within the "moved_to"
column, because that is not the best place.

Committed those remaining comment tweaks in r911393.

Thanks for the review.

- Julian

Re: [RFC] Comments on wc-metadata.sql PRISTINE and

[Greg Stein <gs...@gmail.com>]

WORKING_NODE rows exist for *all* affected nodes.

ACTUAL_NODE rows may exist w/o a corresponding WORKING_NODE row (in
which case, there better be a BASE_NODE row).

In the comments, we should be better about stating null rather than
NULL (as the latter indicates a NULL pointer, not the SQL null value).

moved_here is 1 or something else. There is no need to have a tri-state.

Your comment with respect to moved_to is incomplete. There are more
possible states than just 'base-deleted' and 'normal'. You could also
have (at least) 'not-present' on a child. Consider the sequence: MOVE
A to B. COPY C to A. DELETE A/D. The A/D child will be not-present.

Cheers,
-g

On Wed, Feb 17, 2010 at 13:38, Julian Foad <ju...@wandisco.com> wrote:
> Hey WC-NG folks, please tell me what's right/wrong/unsure in the
> additions and changes below. Feel free to commit any parts that are
> right: I'm not yet familiar enough to really be comfortable committing
> it myself but I will if you want.
>
> - Julian
>
>