I switched from svn to svn+ssh protocoll for a subversion server and configured TortoiseSVN (v1.95) accordingly. This works fine for "update" and "show log" and even repository browser, but when I try to do a commit I get an "authentication failed" error.
Naturally you would think it is a server issue, but it works fine on other computers. Computers where I made a fresh install and also computers that already had the repositories checked out prior to the switch to svn+ssh. It works fine everywhere except on one computer. Same putty version, same Tortoise version, same ssh key. I tried deleting the cached data in Tortoise settings, I made a complete new checkout of the projects, I even deinstalled TortoiseSVN and installed it again...nothing workes. Does anyone have an idea?
EDIT: I found the problem, I use pageant to store my ssh keys. I have 2 and that causes the problem. When I remove 1 it works. But this is merely a workaround. Is there a solution to make it work with 2 keys stored in pageant?
Related
recently I came across something which I can't quite understand and I'd be grateful for any help.
In our company we use GitLab and I've my own key in ~/.ssh/id_rsa. It all worked until I installed openssh-server in order to connect to my workstation via ssh from home. It seems that while typing git pull in the console my GitLab's key is not available (?) and it want me to give a password for a git user. The message is like:
git#gitlab.mycompany.pl password:
I think that after installing openssh-server something must have changed, however I'm not quite sure why. After uninstallation - everything started working again.
I have setup a Vagrant box with Ubuntu 12.04 and Apache2 (all very vanilla, as per Vagrant's tutorial). I've been testing it for web development and I stumbled across a weird issue (not sure if bug or feature):
I have setup a synced folder across my machine and the VM folder. Apache has been serving the files mostly well, except (up to now) for a JSON file I'm using.
If I edit it locally, it seemingly syncs it to the VM folder. Both copies are the same.
Although, if I XHR it from the browser after modifying it, I still get the previously served version of that file.
At first, I thought the browser had it cached, but after trying with 2 different browsers (Chrome(ium) and Firefox), after clearing their respective cache, the issue remained.
I finally managed to go around it by reloading (vagrant reload) the VM.
What I was wondering is if this is a bug or a feature and how can I go around it. Is Apache configurable to not cache server side for a specific folder/file/filetype?
vagrant use previous setting until you provision that new setting again, so after every change in vagrant do provision to see reflected output. There is no apache2 cache problem.
For that use command
vagrant reload vmname --provision
if your vm name is default then use
vagrant reload default --provision
it will reboot vagrant vm and apply change to vm .After provision you will be able to see changes.
Finally figured it out. This relates to an issue that occurs with both Apache and /or Nginx: the sendfile option in server configuration.
Basically a new file wasn't being sent/updated client side even when it was changed server-side by Vagrant sync mechanism.
Check this answer for a solution: here.
On my Jenkins server, I have a project that checks some source code out of SVN and runs a build script called MakeInstaller.ps1 that got checked out along with the source code. It's pretty straight-forward and this part is working great.
What's not working great is that part of MakeInstaller.ps1 attempts to do an svn export of a specific revision of some other source code, but it doesn't have the credentials to connect to SVN. When I run the build-scripts on my PC this is totally fine, because Tortoise SVN has the credentials cached.
Jenkins has my SVN credentials already, but that's only used when Jenkins checks out the source code, not when my build script attempts to check out the source code.
I've tried:
Installing the Tortoise SVN command-line tools on the machine that's running Jenkins. This fixed my initial "svn.exe not found" error, but it has no way of knowing my credentials for this server
I even logged into the SVN server using Tortoise SVN on that machine to attempt it to get it to cache the credentials, but it's still not working. I'm guessing it's because the Jenkins service does not run under the same user that I was logged in as.
I feel like I'm getting off on the wrong path though. It seems a bit odd to have Tortoise SVN installed on that machine along side whatever SVN client the Jenkins SVN plug-in is already using.
My question: Is there a way to do SVN export from inside a build-script in Jenkins and have it use the credentials that Jenkins already knows about? Can I use the same svn.exe that the Jenkins SVN plug-in is using? I really don't want to include the credentials in the build script itself.
Most of the similar questions I found involved the initial check-out failing due to bad credentials, not a check-out that happens as part of the build script.
In the end, I ended up doing something like Jenkins: Access global passwords in powershell
I had to use EnvInject because the Credentials Binding plugin was giving me an error when I tried to save the project. This involved adding another instance of my SVN password to Jenkins, and hardcoding the Jenkins user name into my build script, but it's working.
Now the build script attempts to authenticate with a dummy svn info command. If I'm running the script on my local machine, that works and it proceeds without a user-name or password. If the dummy svn info command fails, it attempts to log in with --username Jenkins and --password $env:svnpassword where the svnpassword environment variable is provided by EnvInject.
Recently I have been plagued by an error on committing to a single SVN repo using TortoiseSVN (1.8.7.25475) or AnkhSVN (2.5.12471.17):
Error running context: The server sent an improper HTTP response
Here is a screenshot of the error in TortoiseSVN:
The pixels differ of course, but the error is the same in AnkhSVN.
This only seems to affect attempts to commit modifications, not additions or deletions; and I can commit mods to several other SVN repos on the same server just fine.
Since my teammates continue to commit mods to the repo in question and the issue has only struck my commits to that repo, I tried committing simple mods after a fresh checkout of the repo: a few one-mod-at-a-time commits worked, but then...same error.
I also searched for, reviewed, and tried some possible solutions (e.g. in a thread on the TortoiseSVN forums to which Stefan Küng replied) - a registry tweak (deleting HKEY_CURRENT_USER\Software\Tigris.org - after exporting it for backup of course), checking my global properties, and ensuring that I am not using a proxy. Same error.
Finally, I tried both repairing and downgrading TortoiseSVN. Same error.
Has anyone else encountered this error under similar circumstances and found a solution to it?
Note that some related search results mention tweaking httpd.conf or other aspects of the SVN server, but server tweaks seem inappropriate to me. Again, my teammates continue to commit mods to the same repo using the same version of TortoiseSVN, the same OS (Win 7 Pro 64-bit) etcetera. Maybe I have missed something on the server that could just happen to affect me, though.
Upgrade your Subversion client to the latest version.
Outdated answer:
ON THE CLIENT MACHINE! Open %APPDATA%\Subversion\servers in a text editor and add the line http-bulk-updates = yes, save the file and see if it helps.
If it helps, you'd better configure Apache HTTP Server's httpd.conf with SVNAllowBulkUpdates prefer directive so that all Subversion 1.8 clients could connect without any errors.
If there are more than just you who get this error in your organization and adjusting server's configuration is still unacceptable, you can change the setting http-bulk-updates = yes via Windows Registry so adjusting this on all affected machines can be done via AD Group Policy.
Read more info in Apache Subversion 1.8 Release Notes.
P.S.: faulty network hardware / firewall / antivirus is still the root cause here. The above is just a workaround to revert to the behavior of Subversion 1.7 and older client with neon network library. BTW, I guess that the installed antivirus is NOD32 or BitDefender.
In my case it was problem with nginx's gzip (I run SVNEdge SVN server behind Nginx).
I disabled gzip and everything started working.
I installed Subversion on a rootserver running CentOS 6. Took me a while, but now I can access the repository using Chrome. I can add files (svn import at command line level), but only when specifying a file:/// path for the destination, https:// giving me "svn: The project archive was moved permanently to [...]; please relocate". I didn't find a single answer helping me with that particular error / message. So I don't even know what it means, what triggers it, ...
On my client I want to use UEStudio (UltraEdit Studio) which has built-in support for Subversion. When trying to do a checkout in UEStudio using the account I created when installing Subversion on the server it tells me "unable to connect to a repository at URL [...]" and also asks for a password. I saved username and password in UEStudio and can login using the exact same credentials in Chrome. The URL UEStudio isn't able to find a repository at is the same I use to browse my repository in Chrome. I'm puzzled!
So I need help setting up Subversion and UEStudio so they finally work together. I cannot offer more details because I'm not sure which ones are necessary. I already spent a couple of hours trying to solve this so I'm not sure what counts any more.
Please feel free to ask for additional details if needed, I'm happy to help!
This Stackoverflow discussion and pointing UEStudio to the x86-version (used x64 so far) of the Subversion client binaries helped, it works now! Also tried UEStudio again and it works as well!! So the problem was I didn't offer a project at checkout, but the parent directory (the repository itself?), as well as offering the x64 binaries to UEStuido.
Thank you for pointing me in the right direction, Robert!! :)