Stefan Sperling <s...@apache.org> writes:
> However, if rep-sharing is enabled, svn_fs_props_changed() does not work
> as advertised because properties do not carry a SHA1 checksum with a
> "uniquifier" which identifies the transaction they were created in.
> The uniquifier is used by svn_fs_props_changed() to tell apart property
> representations which share content but were created in different revisions.
>
> To fix that problem, make FSFS write SHA1 checksums along with uniquifiers
> for file properties, just as it is already done for file content.
>
> A source code comment indicates that SHA1 checksums for property reps
> were not written due to concerns over disk space. In hindsight, this was
> a bad trade-off because it affected correctness of svn_fs_props_changed().
Thinking about this change, it could be that writing the additional 40-byte
SHA1 for the property representations is going to eliminate the benefit of
sharing them in the first place.
If I recall correctly, rep sharing for properties is mostly there to gain
from deduplicating small properties, such as svn:eol-style or svn:keywords.
But with the additional SHA1 written in every representation string, this
overhead is likely to take more space than the property itself.
An alternative approach that might be worth considering here would be:
(1) Extend the on-disk format and allow representation strings without
SHA1, but with the uniquifier, something like this (where "-" stands
for "no SHA1"):
15 0 563 7809 28ef320a82e7bd11eebdf3502d69e608 - 14-g/_5
(The new format would be allowed starting from FSFS 8.)
(2) Use the new format to allow rep sharing for properties that writes
the uniquifier so that svn_fs_props_changed() would work correctly,
and doesn't introduce the overhead of writing SHA1 in the representation
string for every property.
(3) Disable rep sharing for properties in FSFS formats < 8 that cannot
read and write such representation strings without SHA1, but with an
uniquifier.
Barring objections and alternative suggestions, I could give a shot at
implementing this.
Regards,
Evgeny Kotkov
