[MERGE] bzr rm should delete the working file (Bug #82602)
John Arbash Meinel
john at arbash-meinel.com
Thu Apr 12 17:51:48 BST 2007
John Arbash Meinel has voted +0.
Status is now: Waiting
Comment:
This has come quite a ways, and I would really like to see it in 0.16.
If you need some help, just ask, and I can try to do some of the things
I mention here
I think this should have a NOTES WHEN UPGRADING: section in NEWS.
Because it means that 'bzr rm' will change how it works.
I know there have been mention of people who are already using 'bzr rm'
and expecting it to leave the file alone (James Troup mentioned this for
versioning files in /etc). So we need to make sure to convey this change
well. (We aren't destroying the data, you can 'bzr revert' or 'bzr rm
--keep', but people need to know about it).
I don't quite understand this change:
- only 'added' files will be removed. If you specify both, then new
files
- in the specified directories will be removed. If the directories
are
+ only 'added' files will be removed. If you specify both, then new
+ files in the specified directories will be removed. If the
directories are
It seems you re-wrapped the line, only to cause the next line to become
*too* long.
I'm not sure about making these take multiple paths:
def failUnlessExists(self, path):
- """Fail unless path, which may be abs or relative, exists."""
- self.failUnless(osutils.lexists(path),path+" does not exist")
+ """Fail unless path or paths, which may be abs or relative,
exist."""
+ if not isinstance(path, basestring):
+ for p in path:
+ self.failUnlessExists(p)
+ else:
+ self.failUnless(osutils.lexists(path),path+" does not
exist")
I think we generally avoid apis that use 'isinstance'. I'm probably
about 75% okay on this, though. Since it is meant as a way to make
writing tests easier, and as long as the tests are easier to write and
easier to understand, it seems good.
I prefer 'self.run_bzr' to 'self.runbzr', but that is more of a
guideline than a requirement.
PEP8 says that:
(out,err) = self.runbzr(
should be
(out, err) = self.
You added a test class to test_workingtree.py, but it should probably be
a test in workingtree_implementations/test_remove.py
+
+class TestRemove(TestCaseWithTransport):
+ """Tests WorkingTree.remove"""
It needs to be written slightly differently, first by inheriting from
TestCaseWithWorkingTree.
You can look at other 'workingtree_implementations' tests to get a
reference for how to do it.
Putting it in bzrlib/tests/test_workingtree.py means it will be tested
with our current default WT format. Putting it in
workingtree_implementations means it will get tested against all of our
WT implementations (currently WT2, WT3, WT4). The biggest benefit is
that it adds tests for any new implementations, to make sure we maintain
interface consistency.
I don't see why you needed to do this:
- if not tree.has_id(file_id):
+ if not tree.has_id(file_id) or not file_id in
tree.inventory:
If you found a case where "tree.has_id(file_id)" was returning True, but
file_id not in tree.inventory, then you found a bug. And it should be
fixed at the 'has_id()' layer.
As the name might imply,
+++ bzrlib/tests/blackbox/test_too_much.py
Should not have tests added to it. If you find the need to update things
in there, it probably means that they need to be split out into one of
the other blackbox test files. If the test under focus is already
handled elsewhere, then the test_too_much.py test can just be removed.
Lines like this:
+ message="deleted %s"%f
should be:
message = "deleted %s" % f
And I prefer:
message = "deleted %s" % (f,)
Just in case 'f' isn't what you think it is. (If f is a tuple, the
former command will fail with a "Not all arguments handled" error,
rather than just formatting a string with a tuple in it).
changed_files seems like it should be a set() and not a list, though I
don't see you actually using it.
Also I'm worried about:
+ if osutils.lexists(f):
+ if force:
+ # recursively delete f
+ if osutils.isdir(f):
+ osutils.rmtree(f)
+ else:
+ os.unlink(f)
I didn't see that you checked that files underneath the directory under
care are not modified.
So if I do "bzr rm dir" it should fail if "dir/subdir/foo" is currently
modified. We also should have explicit tests for this, to make sure it
stays correct.
I didn't get a chance to review all of your test cases, to make sure you
covered all of the possibilities. But I'll try to do that in the next
review.
For details, see:
http://bundlebuggy.aaronbentley.com/request/%3C418c22640704120143i28986910l4c66d97f588651c3%40mail.gmail.com%3E
More information about the bazaar
mailing list