Behavior of 'rm' and 'mv' under bazaar

[Tom Browder]

On Thu, Sep 30, 2010 at 06:13, Tom Browder <tom.browder at gmail.com> wrote:
> On Thu, Sep 30, 2010 at 01:24, Eric Siegerman <lists08-bzr at davor.org> wrote:
>> On Thu, 2010-09-30 at 11:09 +1000, Ben Finney wrote:
>>> That's right. An OS-level ‘rm’ or ‘mv’ is just another change Bazaar
>>> will track; if you ‘bzr status’ then you'll see Bazaar notices when
>>> files aren't there any more, and will record that fact when you

I've had a little more practical bzr experience now, and the rm thing
is still a little unsettling.  However, I think this work flow will
work from my experiments (please confirm):

I have a bzr rep:

cd repo

# hack on new files a, b, c
bzr add a b c
bzr ci -m"add new files"

# hack on a and b
bzr ci -m"mod files"

# Time goes on for many revisions, file c is forgotten until
# one day I inadvertently remove it with 'rm'.
# I don't notice bzr's msg about c being removed on the
# next commit.
# Time goes on for many more revisions,
# Sometime later I need file c and notice it's gone--panic!
bzr log -v c

I can see the revision where the file was removed, say 10.  Then I can do

  bzr revert -r10 c

And, voila!  There it is at its last committed state.  I have lost any
pending changes from the deletion, but the same thing happens with
subversion.

And, importantly, no other files or directories are changed.

But, and this is different from subversion, c is shown as a new file
which MUST be committed if I want it in the current mainline.

(For this situation, it would be very handy to have a way to ask bzr
for a list of removed files, perhaps an option to 'bzr log'.)

Regards,

-Tom

Thomas M. Browder, Jr.
Niceville, Florida
USA