Does the delta editor guarantee that propchangess are precomposed?

[Malcolm Rowe <ma...@farside.org.uk>]

Afternoon, list,

In one or two places in libsvn_wc/diff.c, we rely on the fact that
propchanges are 'precomposed'.  That is, if a single node has property
changes { [A=>x, B=>y], [A=>z] } over two revisions, the delta editor will
only deliver (via change_file_prop() or change_dir_prop()) the changes
[A=>z, B=>y], rather than call the function twice, once for each batch
of changes.

Is this behaviour currently guaranteed by the tree-delta interface? (and
if so, where?).

If not, would it be better to change the tree-delta interface so it _is_
guaranteed (i.e., document it in svn_delta.h) [and can we make that change
without breaking compatibility?], or would it be better to 'pessimise'
libsvn_wc so that it can deal with the possibility that propchanges are
delivered in batches, even though they aren't (or rather, don't appear
to be).

Regards,
Malcolm

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Does the delta editor guarantee that propchangess are precomposed?

[Jim Blandy <ji...@red-bean.com>]

On 11/8/05, Malcolm Rowe <ma...@farside.org.uk> wrote:
>
> Okay, but in order to build the two trees, it has to combine a set of
> revision deltas. Admittedly, it can't stream back the propchanges as it
> iterates through the deltas, because it has to get the content changes
> combined (or at least identified) first, but that's an implementation
> detail that I shouldn't have to know about.


You're certainly right that, if the interface doesn't promise that each
property's value is presented at most once, its clients shouldn't assume
that. I'm glad Philip says that the extant delta producers do actually
follow this rule; it's nicely consistent with the restrictions on the order
in which producers can call the other editor functions. We made those
restrictions to make life easier for delta consumers; hopefully this
restriction will do the same.

Re: Does the delta editor guarantee that propchangess are precomposed?

[Malcolm Rowe <ma...@farside.org.uk>]

On Tue, Nov 08, 2005 at 07:56:55PM +0000, Philip Martin wrote:
> Malcolm Rowe <ma...@farside.org.uk> writes:
> 
> > In one or two places in libsvn_wc/diff.c, we rely on the fact that
> > propchanges are 'precomposed'.  That is, if a single node has property
> > changes { [A=>x, B=>y], [A=>z] } over two revisions, the delta editor will
> > only deliver (via change_file_prop() or change_dir_prop()) the changes
> > [A=>z, B=>y], rather than call the function twice, once for each batch
> > of changes.
> 
> The repository generates the delta by comparing the two trees, it
> doesn't look at intermediate trees..
> 

Okay, but in order to build the two trees, it has to combine a set of
revision deltas.  Admittedly, it can't stream back the propchanges as it
iterates through the deltas, because it has to get the content changes
combined (or at least identified) first, but that's an implementation
detail that I shouldn't have to know about.

> > Is this behaviour currently guaranteed by the tree-delta interface? (and
> > if so, where?).
> 
> It probably depends on your interpretation of the documentation.
> 

I was just looking at the description of tree deltas in include/svn_wc.h.
It doesn't seem to say whether change_{dir,file}_prop() can be called
more than once for the same property name on a node.

> > If not, would it be better to change the tree-delta interface so it _is_
> > guaranteed (i.e., document it in svn_delta.h) [and can we make that change
> > without breaking compatibility?],
> 
> I don't see any harm in doing that.
> 

Excellent.  I'll do that, then.

Regards,
Malcolm

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Does the delta editor guarantee that propchangess are precomposed?

[Philip Martin <ph...@codematters.co.uk>]

Malcolm Rowe <ma...@farside.org.uk> writes:

> In one or two places in libsvn_wc/diff.c, we rely on the fact that
> propchanges are 'precomposed'.  That is, if a single node has property
> changes { [A=>x, B=>y], [A=>z] } over two revisions, the delta editor will
> only deliver (via change_file_prop() or change_dir_prop()) the changes
> [A=>z, B=>y], rather than call the function twice, once for each batch
> of changes.

The repository generates the delta by comparing the two trees, it
doesn't look at intermediate trees..

> Is this behaviour currently guaranteed by the tree-delta interface? (and
> if so, where?).

It probably depends on your interpretation of the documentation.

> If not, would it be better to change the tree-delta interface so it _is_
> guaranteed (i.e., document it in svn_delta.h) [and can we make that change
> without breaking compatibility?],

I don't see any harm in doing that.

> or would it be better to 'pessimise'
> libsvn_wc so that it can deal with the possibility that propchanges are
> delivered in batches, even though they aren't (or rather, don't appear
> to be).

I think that would be a mistake.

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org