Stefan Küng wrote:
> Nathan Kidd wrote:
>
>> Add a checkbox to the Commit dialog "Ask for Authentication
>> Credentials"
> How would you find out *which* saved auth data to delete?
[snip]
> Deleting *all* stored authentication instead? *no*! People will start
> complaining a lot, and with good reason.
I didn't mean that this should be implemented in Tortoise by deleting
the auth cache. As someone else has suggested, could it not work by
explicitly passing in the credentials so the cache is simply not
queried? Just like I can do on the command line
svn --username=nathan ci
> Just not using the auth cache provider? Maybe. But then, auth data
> also can't be stored, so the auth dialog would have to be modified to
> *not* show the "save authentication data" checkbox. Also, that would
> mean that there's not auth caching during the whole session, which
> means you'll be asked for authentication multiple times.
In the case of commit (which is the only place this is needed) I think
it only asks once, right?
> And the next time you don't check the "ask for auth" checkbox as you
> suggest, the 'old' authentication data will be used again, not the
> last one you've entered while having that checkbox enabled. That will
> confuse people much more than the current behaviour.
This is exactly the behaviour I want -- it only uses these credentials
for that session. To avoid possible confusion, what about changing the
checkbox name to "Commit as different user" and this pops up a separate
"Authentication for This Session" dialog taking the username password,
with no "save" checkbox?
>> Rationale:
>>
>> 1) developer A working with developer B at developer B's desk.
[snip]
> But if you clear the auth cache, developer B will at least know that
> someone else was using his computer again (maybe that's why you don't
> want to do that - because you know that he will be mad at you?)
The key here is "working with". Developer A doesn't want to loose his
saved creds -- he wants, in just this commit, for developer B's
credentials to be used. This kind of situation happens to me regularly.
E.g.
Developer has problem with build system, I go to their machine and work
with the developer to debug this problem (only happening on their
machine), after fixing it I need to commit.
>> 2) a "build" user normally checks out/updates code on build
>> machine, but regularly we find ourselves debugging or tweaking
>> build issues on the build machine and then needing to commit.
>
> Then you should report this on the Subversion mailing list. In that
> case, javahl has a bug and should be fixed.
Yes, I should report it. javahl is just a red herring to this
discussion though. The use-case exists regardless of javahl behaviour.
Without some type of mechanism like this checkbox would provide, it is
difficult to use TortoiseSVN on machines used be more than one person.
> Even if you might argue that 'it's only one simple checkbox', I still
> think it clutters the UI - for something maybe 1% of all people will
> ever need.
I suppose we should all be grateful for your dedication to reducing UI
complexity -- without it we'd have 400 checkboxes, I know. :)
What about an alternative approach:
Add a "More Options >>" button in place of the existing "Keep Locks"
checkbox. This would extend the dialog size and include "Keep Locks",
"Commit as Different User", etc. ?
Best Regards,
-Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Sep 19 18:19:12 2005