[Bug 87548] Re: bzr add and revert on symlink deletes symlink

Aaron Bentley aaron.bentley at utoronto.ca
Tue Jul 17 16:24:11 BST 2007

Hash: SHA1

Kent Gibson wrote:
> Aaron Bentley wrote:
>> Martin Pool wrote:
>>> What I suggest is we 1- fix revert so that newly added files are
>>> deleted (with a backup
>> kept)
>> That sounds good to me.  It would mean we could finally do clean
>> reverts if --no-backup was used.
>> I'd actually be inclined to store the backups in a container, to
>> reduce the amount of cruft that builds up in the tree.
> Are you suggesting a general move away from the .~N~ backup convention?

Yes.  By storing structured data, rather than just a bunch of files, we
would be able to start implementing true undo.

> I'd rather the cruft be where I can find it than hidden in a container.
> And clean-tree does a great job of cruft removal.

Personally, I almost never use the backup files, but I have to deal with
cruft fairly often.  I don't believe that using undo would be a
significant inconvenience, and it would reduce other inconveniences, so
from my perspective, it's a win.

>>> 3- maybe add a revert --keep-added option.  (not so sure - maybe
>>> you should just use remove.)
>> Is this meant to be the current behavior?  Or does it also include
>> automatically-added files?  Symlinks?  I guess I don't really see
>> the need for this, given 1.
> I do see a use for this - I would alias my revert to revert --keep-added.
> The --keep-added should leave all files as is - just unversioned.
> What auto added files are there?  Anything other than .bzrignore?

Anything produced by merge or revert.  I wouldn't count .bzrignore in
that list.

Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the bazaar mailing list