Peter N. Lundblad wrote:
> On Mon, 8 Nov 2004 kfogel@collab.net wrote:
>>lundblad@tigris.org writes:
>>>+++ trunk/subversion/include/svn_wc.h Sun Nov 7 15:50:26 2004
[...]
>>> /** A file @a path was deleted. The [loss of] contents can be seen by
>>>- * comparing @a tmpfile1 and @a tmpfile2.
>>>+ * comparing @a tmpfile1 and @a tmpfile2. Similarly, the [loss of]
>>>+ * properties is provided in @a originalprops. (The list of property changes
>>>+ * is not provided, since it would just be a list of all properties in
>>>+ * @a originalprops with @c NULL values. ### This is inconsistent, what
>>>+ * ### about dropping the file that will always be empty?)
>>> *
>>> * If known, the @c svn:mime-type value of each file is passed into
>>> * @a mimetype1 and @a mimetype2; either or both of the values can
>>
>>I don't really understand the language about properties here. What
>>exactly is provided in 'originalprops'? And what is the parenthetical
>>aside trying to say? Help :-).
>
> Well, originalprops provides the properties on the deleted file.
Peter, I think the comment is wrong. "originalprops" does not contain "the
[loss of] properties" but rather it contains "the original properties" (or "the
properties being lost").
In the original comment, the sentence "The [loss of] contents can be seen by
comparing @a tmpfile1 and @a tmpfile2" means "The (original and new) contents
of the file, and (by inference) the change which consists of losing the
contents, can be seen [...]"
> 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? I don't, however,
> provide a diff in the form of a array of svn_prop_t,
> since, because all properties are going away, it would just be a list of
> all property names with null values. It is different with add, since
> sometimes we provide diffs against the copy source.
The parenthetical aside should probably be removed from the comment, as it is
not a description of the API, but a matter that should be discussed here on
this e-mail list.
- 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:43:39 2004