Doc review & quick ref card - anyone with some DTP skills?

[John Arbash Meinel]

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

Ian Clatworthy wrote:
> Aaron Bentley wrote:
>> Ian Clatworthy wrote:
>>> * It feels a bit weird that both "remove" examples require options.
>> I wholeheartedly agree, which is why I argued against the new behavior
>> of 'remove'.
>>
>>>   What about this ...
>>>     Remove files: bzr remove foo.py
>>>     Unversion but keep files: bzr remove --keep foo.py
>> bzr remove foo is IMHO annoying.  It fails a significant use case: when
>> a user has accidentally versioned a file and wants to undo that.  I
>> think you either want "remove --force" or "remove --keep".

There are major users that expect 'bzr rm' to do --force, and others that
expect '--keep'. It actually seems to be split based on whether the file was
committed. If I do:

bzr add foo
bzr rm foo

Then I would want --keep.

If I do:

bzr add foo
bzr commit
bzr rm foo

Then I would want --force. (maybe --keep if there are local changes, but not as
likely).

Because of these 2 important and different use cases, we gave up and just made
the user supply what they really mean. (I think we might pass the second case
when there are no local changes, but certainly we fail the first).

I think we were also worried about DWIM behavior. Not to mention that we had
quite a few people say "I'm going to alias rm = rm --keep" and another camp
that felt "rm = rm --force".

It was overall a fairly difficult change, because there were very vocal people
which had opposite opinions. Especially when you run into backwards
compatibility (it didn't use to delete them, so it shouldn't now, but it really
 sucks to have to do "bzr rm foo; rm foo".). And while "bzr commit" will
automatically unversion missing files, there is another huge discussion that it
shouldn't be doing that. (mv foo bar; bzr commit, what happened to foo/bar?)


>>
>> And since the normal rm does just fine for "remove --force"...
> 
> I never did digest the nuances of that debate at the time but the
> context of a quick reference card certainly highlights it again. If a
> quick reference card shows two use cases both with options and leaves
> out the "no option" usage, that's got to be a usability warning IMO.
> 
> As you say, the normal rm/del/insert-file-explorer-here works fine so
> perhaps the "Stop tracking and remove" case shouldn't be on the
> QuickRef, any more than move/rename should be.
> 
> Ian C.

Ian-

Earlier you said that "mv" should not be on there, because then it seems like
you have to use it, when you don't because we will "detect" it.

Last I checked, we don't detect renames that didn't go through "bzr mv". Even
if you just use "bzr mv" after the fact. You still have to use "bzr mv".

I don't know what system you were thinking of that detects them when you do it.
But it isn't bzr at this point.

Which is why "move/rename" *should* be on the quickref. (And why rm should be,
too).

John
=:->


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGp6AGJdeBCYSNAAMRAlySAKDHz2h/uwUTUOoD8VOOoo1gyfqmFQCfYL8S
q4fTdXzulfLx2ef67N9tQ3o=
=F/K9
-----END PGP SIGNATURE-----