Re: VC and Tramp

[Stefan Monnier]

> ** One alternative is to use shell-command instead, it decides based
> on default-directory which filename handler to invoke.

Requires quoting of arguments.  Yuck !

> ** Another alternative is to enhance call-process so that it works
> remotely.  But then it is not clear how should call-process find out
> which filename handler to invoke?  (We could define that it does this
> based on default-directory, but I'm not sure that this is a clean
> solution.)  Richard didn't like this idea.

I still fail to see what's wrong with this approach.
Dired uses it with dired-call-process and it works just fine.
Also the question "which handler to invoke" is the same for call-process
as it is for shell-command, so where's the problem ?

> ** Therefore, Richard proposed a new function process-file which
> receives a file name, a command, and command-line arguments as
> parameters, and then uses the file name to determine the filename
> handler to invoke.
> 
> ** Another idea would be to make vc-do-command a filename handler
> operation.

These could work as well.

> * The vc-{rcs,sccs,cvs}-tramp.el approach.

Bad idea.

> I like Richard's suggestion best because I think there are a number of
> other places where a process-file function could be meaningfully used,
> and with his suggestion, all of them would inherit the remote
> functionality.  That'd be nifty.

But the call-process approach is even better since even more programs
use call-process and it's already used by dired.

> The new VC does some things in the background -- vc-do-command
> provides an option for this.  I haven't thought about running things
> in the background, yet.  I'd like to extend Tramp such that it
> provides background commands, but that is not easy to do.  It might be
> very fragile, too.

Indeed.  The only workable solution I can think of is to
create a new connection for each `start-process' (i.e. not try
to get inline methods working).  Basically, amounts to turning

        (start-process name buffer prg args)
into
        (start-process name buffer "ssh" "host" "prg args")

only much harder in order to have it work reliably.

>  Therefore, I wish it was possible to make do
> without asynchronous commands in vc-do-command.  I'm not sure what
> needs to be done such that VC can deal with this situation, where it
> asks for an async command but doesn't get one.  André?

I tried to introduce async operations in as unintrusive a way as I could,
so it should be perfectly fine if the caller requests async operation
but vc-do-command does the operation synchronously.

> I think the other issues can be discussed separately from the ones
> described in this messages.  Here's a short summary, I hope you can
> see whether or not they can indeed be discussed separately:
> 
> - vc-workfile-unchanged-p relies on file modification times.  For some
>   files, Tramp is able to determine the file modification time, for
>   others, it isn't.  For the time being, I have advised
>   vc-workfile-unchanged-p to always invoke vc-backend-diff for Tramp
>   files.

I say don't bother.  It works 100% when you can use Perl to determine
the remote file modtimes.  So just say "VC-over-Tramp requires Perl
in order to work correctly".  It still somewhat works without it I believe,
although rather poorly.

> - vc-checkout has changed a lot, I don't grok the new version.  Not
>   sure what needs to be done here.  But it invokes file modtimes, so
>   the same issue as for vc-workfile-unchanged-p might arise.

I think nothing needs to be done there.

> I'm embarrassed that I didn't have enough time to work on Tramp for
> Emacs 21 (it still doesn't work),

Hmm...it worked fine last time I tried it (not the VC part, of course).


        Stefan