Stefan Fuhrmann <stefan2_at_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
Received on 2017-11-25 21:28:15 CET