On Wednesday, June 9, 2004 at 21:23:10, Matthieu Moy wrote: > 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!
I have seen you comment in tla-file-revert. ;c) Hey but if you really know what you are doing you will not want to go this way ... > 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. I also use it frequently, e.g. instead of doing a find-file I go to the inventory and hit RET on the right file ... > * Someone asked for it. Because he did not knew better. > * 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. Sure, it takes to long. > > - 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 ... O.k. so reverting should be possible from there and ediff. > > - 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. OK. so how about this: Keep all the *-revert functions, but tla-file-revert will display a file-(e)diff, thus you know what changes will be reverted. Then asks the user if he really wants to revert these changes, none or only some of them (goto ediff then). If there were no changes, the user should not be bothered at all, but just get an message that there was nothing to do. By now you still get asked if you want to revert or not. > > 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 Should be covered by the solution above ... > 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) . Thanks, added it to my notes ;c) Cheers Robert
