BZR update (filename) accidentally destroyed my project

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Parth Malwankar wrote:
> On Thu, Apr 8, 2010 at 1:00 PM, Andrew Bennetts
> <andrew.bennetts at canonical.com> wrote:
>> Harry Flink wrote:
>> [...]
>>> Yesterday during compile testing the changed
>>> parts I wanted to revert one file in some
>>> library and ran command:
>>>   bzr update -r1234 myfilename.c
>>>
>>> Well this was a big mistake by my side
>>> because what I meant to do was:
>>>   bzr revert -r1234 myfilename.c
>>>
>> This does seem like a dangerously surprising behaviour to me!  I've
>> filed <https://bugs.launchpad.net/bzr/+bug/557886> about it.  Code-wise
>> the change is simple, but I'm not sure if the existing behaviour is
>> intentional or just an accident.  Anyone know?  I suspect it's an
>> accident.
>>
>> [...]
>>> Too bad there is no undo for "update" (or
>>> any other command) in bazaar.
>> Yes, this is a shame.  Although in a sense this is what “bzr commit” is
>> there for, I understand why it wasn't something you naturally used in
>> this instance.
>>
> 
> As a wishlist, maybe update should fail if there are uncommitted changes.
> Possibly 'update --force' can update a tree with uncommitted changes?
> 
> Regards,
> Parth
> 
> 

Update with uncommitted changes is probably the primary use case.
Perhaps uncommit -r X with uncommitted changes is not, but the former
would be a very strange design.

My guess is that 'update FOO' was not really designed properly. I don't
think update respects a filename, only a path to a working tree. But I
could be wrong.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAku96KsACgkQJdeBCYSNAAOakwCeKPVknzzkltxnDqhi2R3eN4yR
KQEAoJalfbcB4vonbHmN0V3Qf6VgjnNj
=/wlX
-----END PGP SIGNATURE-----