Re: svn commit: r21763 - in branches/1.4.x-r21738/subversion: include libsvn_fs_fs

[Garrett Rooney <ro...@electricjellyfish.net>]

On 10/4/06, malcolm@tigris.org <ma...@tigris.org> wrote:
> Author: malcolm
> Date: Wed Oct  4 05:23:44 2006
> New Revision: 21763
>
> Log:
> On the 1.4.x-r21738 branch: Merge in r21738 from trunk, with the
> exception of the introduction of a new error code, which is not suitable
> for backporting.  Replace uses of that error code with SVN_ERR_FS_CORRUPT.

I've been thinking about this, and I'm not sure that
SVN_ERR_FS_CORRUPT is the right error code to be using.  I mean we're
erroring out to keep things from being corrupted.  How about
SVN_ERR_FS_TRANSACTION_NOT_MUTABLE?  I mean it's sort of a misuse of
the error, but conceptually it is "not mutable" while something else
is writing to it...

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r21763 - in branches/1.4.x-r21738/subversion: include libsvn_fs_fs

[Malcolm Rowe <ma...@farside.org.uk>]

On Wed, Oct 04, 2006 at 09:46:38AM -0400, Garrett Rooney wrote:
> >On the 1.4.x-r21738 branch: Merge in r21738 from trunk, with the
> >exception of the introduction of a new error code, which is not suitable
> >for backporting.  Replace uses of that error code with SVN_ERR_FS_CORRUPT.
> 
> I've been thinking about this, and I'm not sure that
> SVN_ERR_FS_CORRUPT is the right error code to be using.  I mean we're
> erroring out to keep things from being corrupted.  How about
> SVN_ERR_FS_TRANSACTION_NOT_MUTABLE?  I mean it's sort of a misuse of
> the error, but conceptually it is "not mutable" while something else
> is writing to it...
> 

Sure - that seems reasonable.  I confess to being entirely unbothered as
to the exact error code we use for the 1.4.x backport :-)

Regards,
Malcolm