2.0 upgrade experiences

[Martin Pool]

2009/8/13 Andrew Cowie <andrew at operationaldynamics.com>:
> On Wed, 2009-08-12 at 07:36 +1000, Robert Collins wrote:
>> You will have content in .bzr/repository/obsolete-packs that will get
>> cleaned up when you make subsequent commits. We do this to deal with
>> various edge cases without requiring fsync/fdatasync operations (which
>> are either a) expensive, or b) [on XFS and MacOSX] don't work).
>
> So I get why you have to do this on broken platforms, but why oh why are
> those of us running good operating systems penalized for it?

In principle we'd like to do that.  In practice it may be hard to
determine just what exactly is safe, for example ext4 interactions
with other applications caused some surprising data loss.  We'd need
to check the filesystem type too, and perhaps more.

Also, it doesn't seem that unreasonable to me that rather than even
try to work out when it is safe, we transiently use a bit more disk
space that will later be collected.  So I think it's partly a problem
of communication.  On the other hand if the behaviour is too
complicated to explain in a single line, perhaps it must change.

In other words the user problem is not so much "help I'm out of disk"
but "I thought this would shrink it but it grew, wtf?"

Also, the protection we get from doing this is somewhat idealistic.
If your machine does crash and record an incoherent filesystem, it's
probably not going to happen in a nice tidy way, but in a way that
surprises bzr and makes it error.  There may be enough data there for
a bzr developer to help you recover, but bzr won't always recover well
itself.  At least some users will shrug and restore from backups, or
just feel helpless.

-- 
Martin <http://launchpad.net/~mbp/>