hi all, <br>lets try again shall we<br><br><br> ``bzr remove`` and ``bzr rm`` will now remove the working file, if<br> it could be recovered again.<br> This has been done for consistency with svn and the unix rm command.
<br> The old ``remove`` behaviour has been retained in the new option<br> ``bzr remove --keep``, which will just stop versioning the file,<br> but not delete it.<br> ``bzr remove --force`` have been added which will always delete the
<br> files.<br> ``bzr remove`` is also more verbose.<br><br><br><br><br><br><div><span class="gmail_quote">On 4/13/07, <b class="gmail_sendername">John Arbash Meinel</b> <<a href="mailto:john@arbash-meinel.com">
john@arbash-meinel.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Ok. Again, we'd like to see this land by Monday. So ping me if you need
<br>some help. I may not be around a whole lot over the weekend, but other<br>people will be.<br></blockquote></div>Even though I worked late and even through the night, I probably missed the bus :(<br>Hopefully we are a lot closer now though:
<br clear="all"><br> <br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"> John Arbash Meinel wrote:<br> As the name might imply,
<br> +++ bzrlib/tests/blackbox/test_too_much.py<br> <br> Should not have tests added to it. If you find the need to update things<br> in there, it probably means that they need to be split out into one of
<br> the other blackbox test files. If the test under focus is already<br> handled elsewhere, then the test_too_much.py test can just be removed.<br></blockquote><br>I reverted and just did the minimum to get the test to pass again.
<br>I tried to remove the 'remove' and 'rm' tests but a lot of the tests after it <br>depend on it. We should probably see if we can remove the whole thing if these<br>things are tested elsewhere.<br>[DONE]
<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"> John Arbash Meinel wrote:<br> Lines like this:<br> + message="deleted %s"%f
<br> <br> should be:<br> message = "deleted %s" % f<br> <br> And I prefer:<br> message = "deleted %s" % (f,)<br> <br> Just in case 'f' isn't what you think it is. (If f is a tuple, the
<br> former command will fail with a "Not all arguments handled" error,<br> rather than just formatting a string with a tuple in it).<br></blockquote><br>[DONE]<br><br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
Aaron Bentley wrote:<br> If we're going to delete it, let's just delete it. Being "smart" is<br> often stupid. I can't imagine why I'd want "bzr rm" to delete the file,
<br> but if I did, I'd want it to delete the file ALL THE TIME. If you're<br> trying to save me from deleting modified files, then error out if you<br> must, but don't give me inconsistent behavior.
<br></blockquote> <br>[DONE]<br><br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"> John Arbash Meinel wrote: <br> Also I'm worried about:
<br> + if osutils.lexists(f):<br> + if force:<br> + # recursively delete f<br> + if osutils.isdir(f):<br> +
osutils.rmtree(f)<br> + else:<br> + os.unlink(f)<br> <br> I didn't see that you checked that files underneath the directory under<br> care are not modified.
<br> <br> So if I do "bzr rm dir" it should fail if "dir/subdir/foo" is currently<br> modified. We also should have explicit tests for this, to make sure it<br> stays correct.
<br></blockquote><br>[DONE]<br><br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"> Aaron Bentley wrote:<br> Also, it seems like you have a tri-valued parameter here: The deletion
<br> policy may be "auto", "keep", or "force". So it would be best to expose<br> this as a RegistryOption, not a pair of boolean options. That way, "bzr<br> rm --force --keep" will select "keep" as the deletion policy, and an
<br> alias of "rm=rm --keep" can be overriden with "bzr rm --auto".<br> <br> Creating a RegistryOption doesn't have to be onerous; see the<br> from_kwargs factory.<br></blockquote>
<br>[DONE] <br> <br> <br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"> John Arbash Meinel wrote:
<br> Actually, I prefer "run_bzr" to run_bzr_captured....<br> <br> run_bzr is just a wrapper around _captured, which allows you to supply:<br> <br> run_bzr('params', 'to', 'bzr')
<br> <br> rather than<br> <br> run_bzr_captured(['params', 'to', 'bzr'])<br> <br> If only because it is less to type and keep track of.<br> <br> > ok I'll convert to run_bzr_captured,
<br> > but 'self.runbzr' seemed more suited to lazy people like me...<br> > [DONE]<br> ><br> > * these tests follow this pattern:<br> > (out, err) = self.run_bzr_captured
(['remove', '--keep', 'a'])<br> > self.assertEquals(out.strip(), "")<br> > self.assertEquals(err.strip(), "removed a")<br> > which we might want to do better:
<br> > self.run_bzr_captured(['remove', '--keep', 'a'], out_regex='',<br> > err_regex="removed a")<br> > also can't I make it like runbzr, to auto expand a sting?
<br> > (your probably gona say no as you don't like isinstance magic :(<br> <br> We are more okay with testing magic, as long as it ends with easy to<br> understand tests.<br> <br>
We have "(out, err) = self.run_bzr_error([regex1, regex2], 'command',<br> 'to', 'run')"<br> <br> Does that fit what you want? <br></blockquote>
<br>Yes but I also want it with run_bzr (so I moved it there).<br>And I want to be able to say self.run_bzr("commit -m 'howzit!'") <br> so I added that too.<br>[DONE]<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
John Arbash Meinel wrote:<br> I think this should have a NOTES WHEN UPGRADING: section in NEWS.<br> Because it means that 'bzr rm' will change how it works.<br> <br> I know there have been mention of people who are already using 'bzr rm'
<br> and expecting it to leave the file alone (James Troup mentioned this for<br> versioning files in /etc). So we need to make sure to convey this change<br> well. (We aren't destroying the data, you can 'bzr revert' or 'bzr rm
<br> --keep', but people need to know about it).<br></blockquote><br>> Should I just put the whole thing in a the NOTES WHEN UPGRADING section ? ...<br>You didn't respond so I just did that.<br><br>regards
<br>marius<br><br><br>-- <br><br><br><br>I code therefore I am.