Blair Zajac wrote:
> C. Michael Pilato wrote:
>> Blair Zajac wrote:
>>> C. Michael Pilato wrote:
>>>> Blair Zajac wrote:
>>>>> I'm not saying people can't modify it, that's fine, I'm saying, why
>>>>> are
>>>>> we allowing people to remove it? There's a lot of tools that presume
>>>>> the existence of svn:date.
>>>> I think we can pretty much guarantee that every tool that presumes the
>>>> existence of svn:date was conceived and composed after svn:date -- by
>>>> virtue
>>>> of being implemented as a mutable, unversioned revision property --
>>>> was made
>>>> optional. This project needn't bear the responsibility for decisions
>>>> made
>>>> by others who weren't diligent enough to check their assumptions
>>>> against
>>>> reality.
>>> Where does it say that? Even I was surprised to see that its optional
>>> and I work on this project :) I wouldn't fault other projects from
>>> making the same assumption.
>>
>> Allow me to turn this around on you: where does "it" say "that"
>> 'svn:date'
>> will always be around?
>>
>> We provide a collection of property manipulation APIs. Those APIs allow
>> properties to be created, modified, and *deleted*. Not a single one of
>> those APIs describes or implies the presence of any special handling for
>> certain properties. So if you or someone else assumed that the APIs
>> behaved
>> otherwise, you did so without any hints from the APIs themselves.
>
> Because we always talk about svn: being a special protected namespace
> and the only property we ever mentioning changing is svn:log. We don't
> allow people to add new svn: properties without our approval, likewise,
> up to know I assumed we also protected the properties existence.
You've made a wrong assumption about the word "protected". We never claim
to "protect" the properties. We claim to "protect" the *namespace* of some
properties. "Protected" means "This project and this project gets to define
those property names so that we don't accidentally add a new property (and
magic handling thereof) that your project has already been using to mean
something else."
And we only talk (in public) about changing svn:log because it's really,
really rare for someone to accidentally commit with the wrong username
(partially because we don't know each others' authn creds), and because most
folks don't care about tweaking the datestamps. But I can tell you that,
for example, inside CollabNet where it is common for developers to share a
computer, it is *not* uncommon to accidentally commit using the wrong
username (thanks to the authn cred cache) and to need to later change
svn:author to the right value for a given commmit.
> So let me change it on you where it says one wouldn't naturally assume
> svn:date can be deleted. We have the -r {date} which implies its
> existence. Whenever I read the docs for it did it mention it's behavior
> when the property is missing. Does it say in the svn book?
No, the docs are admittedly flawed in this way. If you use -r {date} and
that code has to query a revision that has no datestamp, it raises
SVN_ERR_FS_GENERAL to say that it was asked to lookup a date on a revision
that doesn't have one. (But note that it doesn't raise SVN_ERR_FS_CORRUPT.)
And the book doesn't mention this either (but as you might have seen, I
just sent mail off to svnbook-dev@ to remind us to fix that).
And yes, I can see how the presence of -r {date} at all would lead folks to
assume something about svn:date. So I concede that we didn't do a
super-thorough job in preventing folks from making false assumptions.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-09-27 22:52:55 CEST