Stefan Fuhrmann <stef...@apache.org> writes:
>> 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.)
>
> Yes, that would be one option. If you are willing to provide a patch,
> I would probably +1 it. Not bothering with the space savings would
> be a valid choice as well, IMO.
>>
>> (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.
[...]
>> Barring objections and alternative suggestions, I could give a shot at
>> implementing this.
>
> Go for it. Maybe notify me once you are done b/c currently, I don't
> monitor the commit activity closely.
I committed the implementations of (1) and (2) in
https://svn.apache.org/r1816347 and
https://svn.apache.org/r1816348
respectively.
Thanks,
Evgeny Kotkov
