[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2005-11-08 21:18:04 CET

On Tue, Nov 08, 2005 at 07:56:55PM +0000, Philip Martin wrote:
> Malcolm Rowe <malcolm-svn-dev@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.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 8 21:20:57 2005

This is an archived mail posted to the Subversion Dev mailing list.