On Mon, Apr 13, 2015 at 7:29 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On 13 April 2015 at 20:13, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
> wrote:
> > On Mon, Apr 13, 2015 at 5:01 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>
> > expanded_size is the size of the undeltified (full-text) representation.
> > For properties lists, it can only be 0 for PLAIN representations where
> > the on-disk size is then the full-text size.
> >
> OK. That's make sense. Thanks for explanation.
>
> > On a higher level, the fulltext only contains the serialized "positive"
> > contents. An incremental representation like for directory reps in
> > transactions is not supported by svn_hash_read2. The 'structure'
> > doc does not hint on any support for incremental prop lists nor did
> > it ever work in a previous release.
> >
> What about rep-sharing scenario when prop representation becomes equal
> to result of some text file? Is not prop representation will be
> 'linked' to some delta chain?
>
Positively possible. Deltification as in "txdelta and chains of
txdelta reps" is not a problem - see first paragraph. Shared
reps as well as reps deltified against shared reps look just
the same as "unique" reps. So, if we were to share a file rep
with a prop rep, then the file rep needs to contain at least that
terminating "END\n". Do you have some problematic
constellation that you have in mind?
Deltification as in "incremental hash storage" allows you
to add "removal" entries to serialized hashes, i.e. you can
end up with quite a long textual rep that is effectively an
empty hash. That would be a problem. However, we only
allow that for directory hashes within txns.
-- Stefan^2.
Received on 2015-04-14 17:19:36 CEST