On Tue, 27 Mar 2001, Kim Taylor wrote:
[...]
> Initial (failed) checkin to SCCS of a remote file resulted in remote
> file being deleted and localthe associated tramp buffer too!
Ack! I don't have SCCS, nor do I have access to SCCS anywhere. This
means that it is untested.
I know that RCS works with the VC hacks, but that's it, I fear.
[...]
> Basically, the admin command was passed
> -i/r@METHOD:HOST:/PATH/TO/FILE/ where -iFILE would suffice.
> Compounding the problem, the error wasn't noticed and the file and
> buffer destroyed.
Right. I am not sure /why/ this happened. You might check what the
command passed to `tramp-vc-do-command', `tramp-vc-do-command-new' and
`tramp-vc-simple-command'.
Those actually run the remote command and one of them is clearly getting
the wrong information from VC.
[...]
> A few observations:
>
> 1) The admin command at line [5] was improperly constructed with the
> -i option being passed a filename still in remote syntax.
Yup.
> 2) The error code was noted on line [6]
>
> This is where it begans to unravel. I'd be happy for VC or tramp
> (who's in charge at this point in the sequence?) to simply fail.
I think that the error should have been propagated correctly to VC, but
it's hard to be sure. You might check the above functions to make sure
they return errors correctly when the remote execution fails...
[...]
> I'll be a little wary of remote VC until we get a resolution. I
> couldn't be happier with the basic function provided by tramp itself.
> Many thanks to the development community!!!
I am sorry that the remote VC support broke things for you. If you can
reproduce the problem with RCS, or diagnose exactly what is giving the
wrong information to the `tramp-vc-do*' routines, I am happy to help
with fixing this.
Daniel
--
Real programmers can write assembly code in any language. :-)
-- Larry Wall in <[EMAIL PROTECTED]>
