RFC: handling ignored files in deleted directories.

[Robert Collins]

So we have the ability to ignore files. Ignoring means 'do not auto add'
- but people have multiple reasons not to add a file.

Generally there are two reasons:
 - a file is not valuable (e.g. .o files, *~ files etc)
 - a file is private (e.g. htpasswd or similar)

We have a bug in merge at the moment - a merge that deletes a directory
will fail if any ignored files are present. E.g. foo.pyc. This bites me
routinely during some sorts of code reorganisation.

Now, we could fix this by just removing such files, but possibly this
could lead to data loss when a file that is ignored-and-private is
deleted.

Alternatively we could create a new directory, such as 'lost+found' and
put the ignored files there (still in the directory structure). This
still requires manual intervention, but at least its out of the direct
users way.

Another alternative, a form of which was found in GNU Arch, is to have
another file classifier which extends the concept of ignoring files to
break files into two categories:
 ignored and safe to delete anytime bzr wants
 ignored and not safe to delete anytime bzr wants

*I* would like bzr to not conflict on this case, but I don't want to
setup a data-loss situation for users.

In short:
 - do we want to fix the bug, or should we say WONTFIX?
 - is the potential for dataloss to high to just delete ignored files in
deleted directories?
 - should the default ignore mean 'garbage file' or 'private file' ?
 - how should we implement

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080730/2bd8aa9e/attachment.pgp