Closed GoogleCodeExporter closed 8 years ago
I'm not sure that I understand.
If you enter no username or password then svnX with use Subversion's cached
credentials.
If you enter just a username then svnX with use Subversion's cached password
for that username & repository.
Thus if you enter a username & password in the Repositories list & then just a
username in the Working Copies list (for a WC associated with the
aforementioned repo) you should get what you want.
[Obviously, if you change the repo password you will then need to open the repo
window first to enable Subversion to cache it.]
However, if when you change a password in the Repositories list you are
expecting svnX to automatically replace all identical passwords in the Working
Copies list, then this is not what currently happens.
Note: In svnX 1.2 the username & password info is copied from the list window
when you open a WC or repo window.
Thus you must close & reopen a WC or repo window for any changes to take effect.
Original comment by chris...@gmail.com
on 2 Aug 2010 at 2:51
I tried both methods and it didn't work.
I checked it out using different client, so i think there is nothing cached.
therefore if i provide the username it still doesn't work, for some reason even
if i provide both username and password they don't work. Where is cached
password is kept?
Original comment by ram...@gmail.com
on 2 Aug 2010 at 2:56
If you checked it out using the command line (or any decent) client then any
username/password will have been cached unless you have disabled this.
The cache is stored in "~/.subversion/auth/" & configuration in
"~/.subversion/config".
Explicitly specifying a username/password overrides any caching.
However, if providing a username & password fails then you are probably using
the wrong ones (or don't have the requisite access).
The Info drawer in the Activity window will show any username/password that is
specified explicitly.
It's also possible to have commit access to only part of a repository or
read-only access.
This doesn't look like an svnX issue.
Original comment by chris...@gmail.com
on 2 Aug 2010 at 3:52
The password is definitely correct, as all my other working copies are working
just fine. i looked at config nothing set there, just default file. auth folder
doesn't seem to set anything as well.
Looking at activity log view, if i don't supply username and password for this
working copy it sends username but doesn't send password.
the same working copy works fine under Cornerstone.
Original comment by ram...@gmail.com
on 2 Aug 2010 at 3:59
Based on your original info I was assuming that you had read and adhered to the
instructions
regarding HTTPS authentication in the svnX help.
You implied (or, perhaps, I inferred) that your password was working with your
repository (window).
I now don't think that was correct.
This is what you have to do if "Call Subversion libraries directly" is ON in
Preferences:
1. Enter your username & password in the Repositories list and open the Repository window.
2. Click Accept in the authentication certificate alert.
3. Enter the same username (no password necessary) in the Working Copies list for the associated WC.
This is what you have to do if "Call Subversion libraries directly" is OFF in
Preferences:
1. Execute `svn info <your-repository-URL>` in Terminal.
2. Accept permanently the authentication certificate.
3. Enter the same username (no password necessary) in the Working Copies & Repositories lists in svnX.
[This information could probably be improved in the Help documentation.
However, I think I may be able to make it fully transparent in the next release.]
Original comment by chris...@gmail.com
on 2 Aug 2010 at 7:49
Ok, that actually worked, although the option in the Preferences is disabled,
but calling svn info from terminal did come up with a dialog where i set always
allowed. Thanks!!
Original comment by ram...@gmail.com
on 5 Aug 2010 at 10:36
Interactive SSL (https:) authentication has been added in svnX 1.3b1.
Original comment by chris...@gmail.com
on 16 Sep 2010 at 12:33
Original issue reported on code.google.com by
ram...@gmail.com
on 2 Aug 2010 at 10:16