----- Original Message -----
From: <kfogel@collab.net>
[snip]
> 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
I know. I tried to explain myself and the situation but did not succeed.
> 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).
That's what I tried to do with the patch. I guess the patch is now
outdated since it's made to a revision far in the past.
I admit that failing to get the username on a Linux/Unix system or
on a winNT based system _is_ a fatal error, it is the normal behaviour
on win98 based systems (or any other system where you don't have
to logon).
>
> 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.
Agreed.
> Now, regarding the TSVN behavior you described:
[snip]
> 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
Right. Also the command line client would also _ask_ for a username
and not error out.
> 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.
It'll do that.
>
> And independently of the above, TSVN can/should offer a way to set
> --username and --password in advance of initiating any operation.
I may miss something here but I can't see what this should be good for?
For the command line client is is a good option to pass --username and
--password so you can use the client with a script. But TSVN is not
scriptable and user interaction is always possible.
> So I think if we fix (1) and (2), the rest of the solution is in
> TSVN's domain.
If (1) is fixed, everything will work fine with TSVN (and the CL client
too).
> > 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... :-)
I think the summary is ok. Thanks!
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 5 20:17:24 2003