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

[Martin Pool]

On 7/17/07, Kent Gibson <warthog618 at gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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?

He is, but that's really separate from this change.  All we would need
is a WorkingTree.remove_to_backup (handwave) and later trees could put
them somewhere other than .~n~.

> >> 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?
> Since that is created and added in response to a bzr ignore command I
> wouldn't delete that either - deleting it would be losing some state
> info - equivalent to using --no-backup.

It would be like the current behaviour, except that it should be
consistent across file kinds- newly added files, directories, symlinks
would all be left and unversioned.  I'd be a bit concerned that this
would just cause confusion and people should learn that remove
reverses add...

-- 
Martin