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

Re: svn commit: r11775 - in trunk/subversion: include libsvn_wc

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2004-11-09 00:12:35 CET

kfogel@collab.net wrote:
> "Peter N. Lundblad" <peter@famlundblad.se> writes:
>>Well, originalprops provides the properties on the deleted file. If you
>>provide a diff for an add, you provide the properties (not exactly
>>everywhere, since that's buggy, but anyway). Then it's inconsistent to not
>>provide properties on a file being deleted, isn't it?
[...]
>
> Hmm, no, addition and deletion are not totally symmetrical, and it's
> fine to not provide props on a deletion. Deletion doesn't pay
> attention to content or props, so why would we need the props?

Well, why do we need the content (which was already being provided in the
existing version of this "delete" function)? On 2003-10-25, in thread "[PATCH]
RFC: #2064, new diff_callbacks API", I said:

> Peter N. Lundblad wrote:
>> * For file_deleted, we provide the deleted content, but not the props.
>> They are probably cheap to provide, since the mimetype ought to be
>> fetched if available. Should I add them. I see no use for them in my
>> planned merge changes.
>
> I think you should provide the deleted props. Otherwise there is an inconsistency here which will just be a nuisance in future.

My reasoning was that this "delete" function was presumably providing the
original text of the deleted file for some good reason (e.g. so that a
reversible description of the change could be made) and that if we provide the
original text, then we should, for consistency, provide the original properties
as well.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 9 00:12:51 2004

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