BZR update (filename) accidentally destroyed my project

[Harry Flink]

On Thu, April 8, 2010 10:42, 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.
>>
>> [...]

Andrew, thanks for filing the bug report.

>
> As a wishlist, maybe update should fail if there are uncommitted changes.
> Possibly 'update --force' can update a tree with uncommitted changes?
>

Perhaps but bare update on uncommitted repository
is also very common daily operation when have
checkout'd repository that many users are modifying.

When trying to commit to multiuser repo it is
very common there are already someone else's
changes. Then first one have to "bzr update"
and next "bzr commit" own changes.

Perhaps "bzr update -r<revno>" should require
--force-uncommitted if there are uncommitted
changes as it is feels a little akward thing
to do to update to some other revision when
there are uncommitted changes.

Also I think "bzr update FILENAME" should not
change anything else than FILENAME, at least
not silently. Perhaps
--force-i-know-you-modify-my-whole-checkout
would suffice as a forcing option if it's
really a feature :).

-- 
Best Regards,
Harry Flink