[MERGE] Makeing WorkingTree nicer to derive from.

[Martin Pool]

On 17 Jul 2006, John Arbash Meinel <john at arbash-meinel.com> wrote:

> >>>> Rather than putting a try/except around self._hashcache.write() twice,
> >>>> it might be better to have a helper function in the base working tree.
> >>> or perhaps write() should fail softly.
> >> I wasn't sure where the logic that a failure is okay should be. I kind
> >> of prefer having WorkingTree know about the failure, but just ignore it.
> >>
> >> I suppose we could have hashcache.write() return success/failure.
> > 
> > That would work for me.
> 
> So should a failed write be a warning, or just a mutter?

It would seem to me the only case in which it's OK to fail is if we
physically cannot write to the file: we don't own the tree or it's
readonly or on a readonly volume, etc.  I think all of these can be
detected when opening the result file, or when renaming it into place,
for hashcache implementations that do that.  So there should be an
IOError or OSError catch around just those blocks.

When will a caller want to know if it was actually written or not?  I
can't think of any case except during testing.  So perhaps there should
be an optional parameter.  Or perhaps the tests should just check the
thing was written.

> True. But it means that if someone changes the order of locking, they
> are aware that we were expecting the previous order. I understand we
> don't test 2 codebases. But we can let people know when they change
> something that we expect to work in a certain way.

I agree with John that the locking protocol is part of the specification
for the format and so should (at least in principle) be tested, so that
we make sure not to accidentally change it.  It is a format-specific
thing, and testing it for old formats is arguably not a high priority.

And I'd rather not change the repo/branch order for existing formats
unless we have to.  Yes, the timeout will prevent us from deadlocking
permanently, but the chance of causing both ends to hit a long timeout
is somewhat higher.

-- 
Martin