[RFC] Smoother upgrades

[Martin Pool]

2009/5/14 Jelmer Vernooij <jelmer at samba.org>:
> On Wed, May 13, 2009 at 05:02:06PM +0200, Vincent Ladeuil wrote:
>> >>>>> "Jelmer" == Jelmer Vernooij <jelmer at samba.org> writes:
>
>> <snip/>
>
>>     Jelmer> Some way to remove the backup directories
>>     Jelmer> automatically if the upgrade went ok. Otherwise you
>>     Jelmer> end up having to remove a bunch of those directories
>>     Jelmer> that you have to remove, even if something like
>>     Jelmer> --find/--recurse is available.
>
>> There was a discussion about adding a new command 'bzr clean'
>> that would take care of obsolete-packs and upload, adding
>> backup.bzr there will make more sense IMHO (I like to keep the
>> backups for a couple of days/weeks before deleting them).
>
> I think this operation is common enough to be runnable after upgrade
> (but only if the upgrade was successful). If we separate them users
> might end up removing backup.bzr in places where the upgrade was not
> succesful and end up losing data.
>
> As a side-note I think 'bzr clean' is a confusing name. The name
> doesn't really indicate how it is different from 'bzr clean-tree' and
> git has a 'git clean' command that behaves similarly to 'bzr clean-tree'.
> I much prefer 'bzr garbage-collect' (did that have the same function?) that
> was proposed earlier.

I agree that 'bzr clean' should probably mean 'clean-tree'.

On the other hand I think it's a bit poor that git overloads everyday
operations onto the gc command[*] which can also potentially remove
data, and I wouldn't want to follow that.

Removing the backup directory, which is a kind of detritus in the
tree, plausibly is a function of clean-tree.

Removing obsolete packs to me is still part of the general operation
of the 'pack' command, ie 'tidy up the internals of the repository,
losslessly'.  Probably you'd want an option to say 'don't actually
pack, just tidy up' and I do see the point that options that subvert
the main meaning of the command are undesirable, all other things
being equal.

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

[*] Anything I say about git may of course be out of date.