On Fri, 2005-04-01 at 14:14 -0500, Stefan Monnier wrote: > Am I right in believing that this is a problem specific to vc-rcs.el?
I know of no other occurences, and I'd be happy to localize changes into vc-rcs.el as much as possible. Michael Albinus has stated, however (on tramp-devel), that "such a function is on my wishlist for a while, not only because of vc." He didn't give any more details, so I'll put him in copy and ask him to let us know why he would like something like "file-calling-user", except for the use in vc-rcs.el. > Couldn't vc-rcs.el use RCS directly instead of reproducing RCS's > behavior? > I.e. just try a dry-run of `co', and see if it fails? I did things like that when I first made patches to VC, but we decided against that at the time; it was just too slow, although it is perhaps clean conceptually. The "dry-run" of co seems very much like a kludge to me, though. > Or otherwise run (shell-command "id") since shell-command is a fileop that > can be caught by file-name-handlers and run on the remote host. That sounds like a very interesting alternative, maybe better than file-calling-user. > I just feel that adding a global command is difficult to justify just for > the odd case where all the following conditions are met: > - you're using vc-rcs.el. > - you're using it over Tramp. > - you've played with the permissions such that they don't give us directly > the proper information about whether a file is locked. Well number one is not odd at all, RCS is still a widely used version control systems at many sites. Number three is also not very unlikely -- as I said, I've seen things like that happen at almost every site where RCS is used. It is very common that clueless users (or lazy ones) simply change the permissions of a file to make it "work", without realizing that they are circumventing RCS this way. (I got a bug report from someone who managed to get himself into trouble this way just this present week.) VC has the potential to handle these cases much more gracefully than RCS does on its own. Number two in your list is what's not working currently, and we're only trying to achieve it for reasons of consistency. As I said, I'd be happy to make the change as local to vc-rcs.el as possible. I can certainly envision Tramp-specific code in VC, because it's just another standard part of Emacs. But maybe a more general solution is in fact called for. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
