On Mon, 8 Aug 2005, Julian Foad wrote:
> Peter N. Lundblad wrote:
> > AFAICT, it didn't:-( I think a problematic thing is the
> > SVN_ERR_IS_LOCK_ERROR macro that hardcodes which errors are non-fatal
> > locking errors. That's a public macro:-(
> Goodness knows how we allowed that to become a public macro. It seems to be
> just a convenience for the RA layers.
It was converted from a function to a macro in r13618 FWIW. I don't know
why, but it does't matter that much.
> Fortunately, changing the implementation of it won't break binary or source
> compatibility (at least not directly, if it has been used sensibly). But
> anyway, even if we can't change it, it doesn't matter because we don't have to
> use it.
Good points. I think deprecation is best here.
> So that's not a problem. Would you care to propose a fix, or shall we file
> this bug in the issue tracker?
Might be better to try to get it resolved right away. Let's start with
the subject of this mail: what errors should be considered non-fatal.
Since the RA layers take multiple paths, this is not up to the clients
(but it is still on the client side of the RA layers in code that we have
Note that I don't remember any design discussions regarding which errors
should be non-fatal. That's why I'm not sure about the rationale for some
of the errors. Maybe fitz can clarify somewhat here.
I've been trying to come up with a proposal regarding which errors should
and shouldn't be warnings, but I'm getting stuck. I think I need the
following question answered first:
- what is our general policy regarding when something is a warning or an
For example, if I try to lock a file in my WC and I already have it locked
in this WC, then you could view the locking operation as a no-op
(forgetting about metadata such as creation time and lock comment). But
when I try to lock a file locked by me, but without a lock token in this
WC, or if I'm locking a file that is out-of-date, why is that error less
fatal than a "path doesn't exist" error? I'm afraid I don't get the
Someone with a more well-organized head than me needs to sort this out
before we can get any further. Sorry for this confused mail, but Julian,
now you know why this answer is a little late...
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Aug 10 12:38:50 2005