[BUG] Can't remove non-existant file

[Martin Pool]

On 26 May 2005, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> Hi again,
> 
> If we apply the fix from my "half-constructed Branch" email, we still
> can't remove a non existant file.
> 
> abentley at troll:~/bzrtools2$ bzr remove .be
> bzr: error: u'/home/abentley/bzrtools2/.be' does not exist
> ~  at /home/abentley/bzr.dev/bzrlib/branch.py:64 in find_branch_root()
> ~  see ~/.bzr.log for debug information
> 
> This comes from the fact that you determine the branch root from the
> first parameter, not the cwd.
> 
> My knee-jerk reaction is to do os.path.dirname() on the argument to
> find_branch_root.  That would fix this case, but what if I tried this:
> $ bzr remove .be/bugs
> 
> Now neither the argument, nor its parent directory exists.  Greaaaat.
> 
> So on the one hand, we could recursively scan up until we hit a parent
> directory that *does* exist.  But that can cause typos to have
> exceedingly weird results-- we can wind up in a versioned directory
> several levels higher.

Yes, I agree.

It's interesting to see how this is handled in other systems; I have
often been annoyed by (iirc) cvs and svn's inability to operate on
files inside a working directory other than cwd, but had not thought 
much about exactly what is is needed for dwim before this.

> I think a possibly-sane approach would be to use tree-root of the cwd as
> a stop-directory for the scan.  But that would mean that you'd never be
> able to remove files in a different working tree from the cwd's tree.
> (Except children of the cwd).

But that kind of mixes two cases of using the cwd and the path...

> I think this is all way too heuristic to have in the Branch constructor.
> ~  I'd be much happier to see factory functions/methods called
> init_branch and find_branch instead of the init_branch and find_branch
> constructor options.

Yes, I think you're right.

I might add an option to the find_branch factory that says it's OK for
the filename not to exist.  Only a few commands such as status and
remove will want to set this, and if the wrong branch is found then
they will trap later on when they try to look up the path in the inventory.
(Not sure if that will really work but it feels right.)

> As a bonus, that would also solve the "half-constructed" issue.

I think that is partly a bug in cgitb; I wonder if it should perhaps 
catch exceptions when it tries to take the repr of various values.

-- 
Martin