Robert Widhopf-Fenk <[EMAIL PROTECTED]> writes:

> - in inventory mode I do not know if the file has changed or
>   not (or did I miss a new gimmick).  You may even type "U"
>   on any file giving you an error without a reasonable
>   message for junk files.  So why should we allow this
>   command in inventory mode, it does "not" change es
>   inventory?

Clear, I  don't like the idea  of reverting a file  from the inventory
buffer. Actually, I don't like  the inventory buffer at all, which may
explain that ;-)

And actually,  I don't  like the  idea of reverting  a buffer  at all.
Reverting from ediff, hunk by hunk, is a much safer alternative in 99%
cases!

But still:

* Some people like their inventory  buffer and seem never to leave it.
  Seems fair to allow them to  use this buffer as a starting point for
  most operations.

* Someone asked for it. 

* On a large  tree, running tla-changes may be a bit  long, so, if you
  know what you're doing, and  if you already have an inventory buffer
  open, then, reverting from the inventory buffer is the right choice.

> - Before reverting, the user should inspect the changes in
>   order to ensure nothing will be lost.  And where do we do
>   that? In tla-changes ... 

or tla-file-diff ... 

> - the last one is more an educating reason, 

This is  an acceptable reason. Not  sufficient in my  opinion, but I'm
still open for discussion.

>   but for the
>   same reason I would remove tla-file-revert.

Ah,  one "detail" :  both tla-changes-revert  and tla-inventory-revert
are wrappers arount tla-file-revert. 

So, I'd advise you NOT to remove this function ;-) But we could remove
the (interactive) statement!

I also don't think this is a good idea, because if the user knows what
he's  doing (eg.  He's  just  ran tla-file-diff),  then,  from a  file
buffer, running M-x tla-file-revert RET yes RET is much faster than

1) C-c T c & wait for tla changes the process to complete

2) Find the file in the list

3) 'U'

And the  step 2) is  also error-prone if  you have several  files with
similar names,  so it  may be  better to revert  from the  file buffer
itself)

> - and then  there is the point below. Actually I  deleted an file by
> accident today and  I resurrected it by getting  the latest revision
> in /tmp  and copying the file from  there, since this way  I did not
> need to look up some docs ...

We clearly have something to add here. There shouldn't be much to do. 

PS: the answer was

 cp $(tla file-find foo) . 

-- 
Matthieu

Reply via email to