On Wed, Jan 09, 2002 at 10:15:47AM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gstein@lyra.org> writes:
>...
> > The property just shouldn't be sent. If the values are NULL, then the
> > properties don't exist. "" is an empty author.
>
> No, actually, the property should always be sent; if it's not sent,
> the client could end up with a valid CR and 'stale' (non-matching)
> author/date props in the entries file.
>
> However, I agree with you that if the value in the fs is NULL, we
> shouldn't be sending an empty prop value; we should be sending a
> <remove-prop>. I'll fix that now.
Alternatively: the client can use their absence to imply an empty prop
value.
Hmmm... I guess it really depends on what the server "means" when a NULL
arrives there. i.e. the difference between "I am not supplying that" and "it
is not present [and should be removed]." If the former, then omit the prop
and the remove-prop, if the latter, then use the remove-prop.
>...
> > I would recommend just omitting the property rather than substituting an
> > empty string. The two seem to be very different.
>
> As I said above, we always have to send the 3 props, even if some of
> them are non-existent. We don't want the 3 props to ever be
> out-of-sync with each other in the entries file.
Sure. And synchronizing the client side is a different/separate issue from
what travels over the wire (and its particular semantics). If the prop isn't
provided on the wire (for whatever the reason), then the *client* can
determine how best to handle that. And it could say "don't let them fall out
of sync; I'm gonna do <X>".
> So why not remove the entry attribute when we receive a NULL value?
>
> Karl and I had a chat about this. Here's the deal: the wc update
> editor's close_file() writes a zillion log commands, then runs the
> log. Unfortunately, our log command that tweaks the entries file
> doesn't have the facility to remove entry attributes -- believe it or
> not! I don't think we've ever had entry fields that have 'vanished'
> before. So we decided -- rather than rewrite this interface -- that a
> NULL value for a date or author prop should just be changed to a "" in
> the entry attribute. Really, the entries file isn't a true props
> database; there's no reason that we have to obey the "NULL implies
> delete" rule. The keyword substitution engine certainly won't care if
> the value of the author attribute is "".
All true, but absence of data is different from data that happens to be
empty. It seems that we can't model a case where there is no author. (not
sure that we'd want to, of course :-)
*shrug* Not too bothered by it all, but it seems there could be a small
margin of Better.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:55 2006