Lübbe Onken <L.Onken@rac.de> writes:
> since we are having the same problem here (5 developers on Win98), we are
> very much interested into getting that patch into SVN too.
>
> [...]
>
> IMHO Subversions login handling is not really user friendly. For instance:
> If I connect to a password protected repository for the fist time,
> Subversion tries to connect with my windows user ID (yes I know about
> --username) and asks for my windows password. If this fails, SVN asks me for
> another UID and the corresponding password.
> On a Win98 client Subversion cannot get a UID and fails instantly instead of
> trying to request the necessary information from the user as it does on
> other OSes if the login fails for some other reason.
> Not very smart, from a users point of view.
Agreed. I've CC'd the dev list, since this is now getting into the
territory of a behavior change.
If you read this whole thread, there is no consensus on Stefan's patch
as a solution:
http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=101363
The first thing I'd like to do is get a clear, concise description of
exactly what the bug is, and file an issue. This is not specific to
just Win98, but to any system where getuid() could fail. (I know this
insistence on an issue might seem like reflexive bureaucracy, but I
find it makes it much easier to understand & solve the problem.)
Your mail is the closest we've gotten to a summary so far; let me try
to boil it down further:
1) Right now, failing to get the username from the system is a
fatal error. It would be better if when the client fails to get
a username from the system, it would simply prompt the user
(just as if it had gotten a username, but that username had
failed the authentication challenge with the repository).
2) If the client gets a username (by any means), that username
should always be cached *unless* it fails an authentication
challenge. In other words, if no challenge happens, but we have
auth parameters available, then cache them -- it can't hurt.
Now, regarding the TSVN behavior you described:
> A different thing is, that with TSVN as a client, I have no chance of
> telling SVN beforehand which UID I want to use when I connect to a
> repository, until the login credentials are cached by SVN. In this case I
> have to let the first login attempt fail (confusing, but I know that by
> now), before I get my second chance to enter the correct UID/password.
>
> I don't know if TSVN has a chance to work around the above behaviour (I'll
> ask on the TSVN list), but I think it would be nice, if upon the first
> connect, the SVN API would provide a response to the client like:
> "trying to connect with username:" <Username>.
> If SVN couldn't get a UID (eg. win98), the username string would be blank.
> Now different clients can react differently:
> - The command line client can still try to connect to the repository
> immediately using the provided username, asking only for a password, or ask
> for a uid/password if the username is blank.
> - TSVN (or any other GUI client) can pop up a username/password dialog,
> where the UID is already filled in.
It seems to me if we fix problem (1) from my list above, then TSVN
will just Do The Right Thing automatically, right? Internally, the
svn client will try to get a username from the system, and then maybe
from the cache. If it fails, the first user-visible thing it will do
is prompt. TSVN can see this, and propagate the prompt to the user.
And independently of the above, TSVN can/should offer a way to set
--username and --password in advance of initiating any operation.
So I think if we fix (1) and (2), the rest of the solution is in
TSVN's domain.
> This way we could get around that confusing "fail once, success later"
> behaviour.
Yup, that would be nice.
Folks, have I summarized this problem correctly, or am I missing
something important here? Feedback welcome, please get to me before I
file an issue... :-)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 5 18:42:41 2003