Code review comment for lp:~vila/bzr/323111-orphan-config-option

Martin Pool wrote:
[...]
> I think the always/never distinction is not the right dimension though,
> because it seems to assume there is one thing that we want to have either on
> or off. But I think what we want is, well, actually different policies, which
> might include:
>
> * conflict: mark the directory conflicted and don't remove it
> * unversion: mark the containing directory unversioned, but leave it in the tree
> * move: move them to a bzr-orphans directory in the root of the tree
> * delete: just immediately delete them

This is a great way to put it, that's what I was thinking too.

For example, I'm imagining plugins adding support for:

orphans = vary_by_file_ext
orphan_policies = pyc:delete,*:move

(as a not very carefully designed strawman...)

Similarly, it would be lovely if support for 'precious' files could be done
initially by a plugin...

> > I made the factory accept a simple callable as requiring a TreeTransform method
>
> I think, generally, I'm against any interface taking a pure callable. (I was
> just regretting one I added myself in Launchpad feature flags.) So often it
> turns out that you also want to ask the thing passed in for a description of
> itself, or something like that. Passing an object with a well-known method
> name gives a bit more room to move.

See also our hook registration API, which asks for a description for its
callables :)