[IMHO the wiki is kind of inconvenient for discussion, so I
quote it here]
Removing tla-file-revert and tla-inventory-revert in favor
for a tla-changes-revert.
> > - tla-file-revert already exist. tla-inventory-revert is
> > also implemented and bound to 'U', but I suggest you
> > revert files from the *tla-changes* buffer, with
> > tla-changes-revert, bound to the same key. Also, reverting
> > a file blindly is usually not a good idea. C-x T e will
> > open an ediff session with the original file, you can
> > revert patch hunks one by one, then save the file.
> >
> > + I like the idea, maybe we should even remove the other
> > two functions in favour of tla-changes-revert.
Matthieu said:
> - I don't agree about removing tla-inventory-revert
> because 1) I've implemented it following the demand
> here ;-) 2) tla-inventory and tla-changes both
> provide a list of files and should provide roughly
> the same set of features. (MatthieuMoy)
My reasons are:
- 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?
- 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 ...
- the last one is more an educating reason, but for the
same reason I would remove tla-file-revert.
- 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 ...
> > + Further the existing functions do not allow to revert
> > (resurrect) a deleted file. -- ?RobertWidhopf
but in the tla-changes buffer we have the file and
the information already present!
Robert.
