Re: Tramp advises vc-user-login-name, how to remove?

[Kai Großjohann]

Andre Spiegel <address@hidden> writes:

> On Sun, 2005-03-27 at 15:10 +0200, Kai Großjohann wrote:
>
>> In some cases, VC uses file-attributes to obain the uid of a file,
>> then uses vc-user-login-name to obtain the login name of that uid.
>> 
>> In these cases, VC could call file-attributes with the new optional
>> arg ID-FORMAT equal to `string', instead.
>
> Yes, this is adequately implemented in file-attributes now.  Please feel
> free to make the appropriate changes in vc-*.el.
>
>> In one case, VC uses vc-user-login-name to obtain the login name of
>> the currently logged in user.  This is in
>> vc-default-update-changelog.  Would it work to just call
>> user-login-name instead?
>
> The problem with user-login-name is that it may return nil if the
> uid cannot be resolved.  I want VC to use the uid as a string in
> this case, that's why vc-user-login-name was introduced.  How does
> this interplay with Tramp?  I've looked at the code, but I cannot
> understand the situation entirely.

I also don't understand how it would interplay with Tramp.  If I'm
user kai on the local box, and editing a remote file as user kgrossjo
on another host, should VC then use kai or kgrossjo in
vc-default-update-changelog?

(It gets slightly more complicated in that it is possible to omit the
user name from the Tramp filename, and then Tramp does not currently
know what is the user name on the remote system.  But I guess it would
be easy enough to have Tramp invoke "whoami" or somesuch to find out.)

>> It seems the call in vc-rcs-state-heuristic could also use the new
>> ID-FORMAT arg of file-attributes.  Right?
>
> Yes.
>
>> Could vc-rcs-fetch-master-state use user-login-name?  What is the
>> intent of that comparison?
>
> If the file is locked by the calling user, that means he can edit it.
> If it's locked by somebody else, he shouldn't.  That's why the
> comparison is done.  Now, if user-login-name cannot be resolved and
> returns nil, that likely means the file is not locked by that user.  At
> least we are on the safe side if we consider that as "locked by somebody
> else".  Therefore, yes, I think user-login-name would do in this case.

Okay, so if I'm kai on the local box and kgrossjo on the remote box,
then vc-rcs-fetch-master-state should compare the locking user against
the name kgrossjo.

This means that user-login-name does NOT do the trick.

>> Could vc-rcs-consult-headers use user-login-name?  What is the intent
>> of that comparison?
>
> Same thing as above.  The name of the locking user is included in the
> headers, just as it is in the master file.  user-login-name looks safe
> to me here as well.

Okay.  So user-login-name also does NOT work here.

>> Could the call in vc-sccs-state-heuristic use the new ID-FORMAT arg?
>
> Yes, same as with RCS.
>
>> What should vc-sccs-state do?
>
> Same logic as with vc-rcs-fetch-master-state.  user-login name should be
> okay.
>
> Hope this helps.  Thanks for working this out.  I'm still too busy
> with other projects that I could invest significant time into it
> right now.

Hah!  Working this out.  You wish.  I merely took the first step.
Many more steps to go.

My other project is called Eva.  This project has been ongoing for 18
months now, and it means I will still be too busy for some years to
come :-)  I wonder if Eva will be joined by another project...

Kai