This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
We have a very large codebase in multiple svn repositories of which I use two. Must of the time I manage svn details on the command line, but occasionally (because NB does not notice when things have been checked in), I'll do an update to HEAD within NB, and it appears to assume that the credentials for all repositories are the same. I have svn configured to use cli, so I really don't see why NB would not get authentication right. The cli stores the password on disk, and has no trouble doing queries on either repository, but when NB does an update, I invariably get asked for passwords on both repositories. This is where I see that it uses the last password typed in, which of course, is always wrong for one of them. My guess is that NB always uses the --username and --password arguments. Since the cli stores the password, one solution would be to have an option to not try to authenticate. The other option is to figure out how to handle multiple repos. Product Version: NetBeans IDE Dev (Build 201409241121) Updates: Updates available Java: 1.7.0_45; Java HotSpot(TM) Client VM 24.45-b08 Runtime: Java(TM) SE Runtime Environment 1.7.0_45-b18 System: Linux version 3.12.6-200.fc19.x86_64 running on i386; UTF-8; en_US (nb) User directory: /home/toddb/.netbeans/dev Cache directory: /home/toddb/.cache/netbeans/dev
I don't get it. If you have two checkouts (for two repositories) and update them (one by one?) then NB uses cached username and password for them separately. It keeps them cached under a key which is the repository URL, so as long as you use two different repos different username+password should be used. Or are the checkouts nested? Please describe your setup a bit and let me know how you update the repos (one by one?)
Ok, thanks for asking. I think I understand what you are saying *should* happen. In my usage of svn inside NB it is only ever to update a single directory in a single repository. However, not matter which repository the directory falls in, events proceed in one of two scenarios. There are two login/pw authentications... call them authA and authB. Scenario 1: - kde wallet asks me for my wallet password - a dialog titled "Authentication failed" pops up with authA, which is correct for the repo. - I hit enter, and authentication fails again, and the dialog comes back. - I type in authB and it fails again, and the dialog comes back. - I type in authA and it succeeds. Scenario 2: - kde wallet asks me for my wallet password (unless recently given) - a dialog titled "Authentication failed" pops up with authB, which is incorrect for the repo. - I hit enter, and authentication fails again, and the dialog comes back. - I type in authA and it succeeds. Could it be that kde wallet is getting in the way? I still don't see why the wallet needs to be involved if the cli is being used, although it makes sense for the integrated version.
I do not know. For me NB always fetches the correct credentials for each repository and passes them to CLI. > I still don't see why the wallet needs to be involved if the cli is being used, although it makes sense for the integrated version. Exactly as you deduced. NB handles auth itself, always passes cached credentials to CLI as --username and --password. We cannot be sure if user has his setup correct so we handle authentication credentials ourselves. So the question i why in your case credentials for the two repos are mixed in NetBeans. Can you please start NetBeans with -J-Dorg.netbeans.modules.subversion.level=FINE ? IDE will then print to log commands it starts so you can check and verify the credentials passed to CLI. Start an update for one of the folders and check the log then when it fails. Subversion module is pretty chatty, so the log will be flooded, search for > cli: Executing "svn update -r HEAD or just "svn update". And let me know if the credentials are correct or not (or belong to the other repository). Few more questions: 1) do you use the same username for both repos? And just a different password? 2) What are the repository URLs? It could be they look pretty much same to NB and it caches them under a common key. Then if you realize the passed credentials to CLI are really incorrect, could you run the IDE with: -J-Dversioning.util.KeyringSupport.level=-1 -J-Dversioning.keyring.logpassword=true and then check the log again after an update? These should result in printing communication with kwallet and we should find out what is really saved in keyring and what password Subversion module asks for. Search for > versioning.util.KeyringSupport]: Getting password: > e.g. FINEST [versioning.util.KeyringSupport]: Getting password: versioning.subversion.:REPOSITORY_URL -- "PASSWORD" in the log and check the password is correct for the given URL.
Created attachment 150136 [details] log file log with -J-Dorg.netbeans.modules.subversion.level=FINE
Created attachment 150137 [details] log Actually, I think the log blew past its limit. I think these are three adjacent logs.
Created attachment 150138 [details] log for -J-Dversioning.util.KeyringSupport.level=-1 -J-Dversioning.keyring.logpassword=true
> We cannot be sure if user has his setup correct so we handle authentication credentials ourselves. Perhaps make authentication an option of cli is selected? > And let me know if the credentials are correct or not (or belong to the other repository). As above, I think the log blew past the end. And yes, it got the auth incorrect. I should note that 'Manage Connection Settings" only presented one repository. > 1) do you use the same username for both repos? And just a different password? No. Both user and pw are different. > 2) What are the repository URLs? http://hood/svnroot/repo/PNP/Spectrum/branches/_sandboxes/APP/Spectrum/omneon http://hsvn/svn/repo/Libraries/libmapi/trunk/libmapi > Then if you realize the passed credentials to CLI are really incorrect, could you run the IDE with: -J-Dversioning.util.KeyringSupport.level=-1 -J-Dversioning.keyring.logpassword=true They were not incorrect, although NB apparently applied them in a way that was incorrect. Anyway I attached logs (and I changed my password from the one in the log). I note that the password was correct, but I did not see a record of the user. Note that the two users for the svn urls are different than my unix login.