William Ferguson wrote:
> --- Malcolm Rowe <malcolm-svn-dev@farside.org.uk>
> wrote:
>
>> FWIW, I agree. I don't think William is particularly
>> bothered about how
>> this situation manifests itself, as long as it can
>> be reliably identified.
>
> I don't think that returning SVN_ERR_FS_NOT_DIRECTORY
> is the appropriate response for svn_ra_stat. It
> probably is for some lower-level function that is
> targetting a file system, but svn_ra_stat is
> targetting a logical resource path - ie there is no
> reason that it needs to map down to any kind of file
> system.
In an ideal world, perhaps we would have named the constant
SVN_ERR_NOT_DIRECTORY, leaving out the _FS_ segment, but, to look at it
another way, if you are accessing a subversion repository via the RA
(repository access) API, then by definition, the reepository you are
accessing contains a Subversion FS (file system). I.e., yes, there is an
absolutely perfect reason to map down to a Subversion file system.
> Not only that but SVN_ERR_FS_NOT_DIRECTORY is a bit of
> a misnomer since the path that was supplied to
> svn_ra_stat doesn't have to be a directory, just all
> the parent paths.
The simple phrase 'NOT_DIRECTORY' does not qualify that if necessarily
applies to the argument itself, rather than a step on the way to processing
that argument.
> I firmly believe that svn_ra_stat's reponsibility (as
> currently described in the function doco) is to
> clearly indicate the details of the supplied path,
> which includes a NULL dirent_t* if the path does not
> exist - which is the case in this scenario.
I firmly believe that there is an important distinction between 'not
existing' and 'being obstructed by a file at a parent level', and that some
consumers of this API will want to be aware of the distinction.
To give an example: an application may wish to ask a user whether to create
a nonexistent path, but would be wrong to ask whether to create an
obstructed path.
> But if you decide to go with returning
> SVN_ERR_FS_NOT_DIRECTORY and upgrading the doco, then
> I guess I'll leave my hack in place and extend it to
> all uses of svn_ra_stat just to be safe.
Inspecting and ignoring certain errors in certain cases is not a hack, it is
proper programming practice.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 14 13:36:42 2005