A few remarks on the code I've just merged: 1) The function tla--in-version-tree was a duplicate of `tla-tree-version'. I've removed it.
1-bis) Note: I'm sometimes working on a machine where the command "tla" is actually a wrapper calling tla remotely through rsh. In particular, it makes it very slow to start (~1 sec). Since this is the suggested approach for people working on NFS (http://wiki.gnuarch.org/moin.cgi/NfsWorkplaces) I suppose I'm not the only one. We don't need to call an external process to read the content of the file {arch}/++tree-version, so, tla-tree-version is written in pure elisp. It will be a bit faster for people using tla locally, and *much* faster for people like me running tla remotely. 2) It is completely possible to run tla-get-changeset outside a local tree. tla will just download the patch (and only this patch) from the archive and save it locally. The bug [EMAIL PROTECTED] tries to fix was actually a bug in tla--get-buffer-create. It is fixed in my archive, and I've reverted tla-get-changeset. 3) Inspired by 2) : What should we do to reject a patch? The trivial approach is to merge the patch, revert it manually, and commit, but xtla should provide a cleaner way I think. First step is most probably to star-merge up to the previous patch, then we should provide an command "reject next patch", and then, star-merge the next ones. Another option : select patches to be applied with `m' in a revision list buffer, and use "tla replay" on the selected patches. -- Matthieu
