On Linux Mint 17 with Subversion 1.8.x I have problem with committing files to SVN - I obtain error: "svn: E120105: Error running context: The server sent an improper HTTP response".
What works on another computer with older system version is subversion 1.7.x.
I tried many things to fix it (overview is here - http://jankoweb.moxo.cz/blog/open-source/svn-error-the-server-sent-an-improper-http-response-pri-commitu/) but nothing works for me.
Do you know how to fix this problem on Linux?
I believe the issue is that the working copy format has been changed in svn 1.8.x, so you've two options I can think of:
1) run svn upgrade on the working copy. This may take a while depending on the size of the working copy, but it should sort things.
2) Check out a fresh working copy and use that, if you don't have too many changes to redo since the last checkout.
Hope that helps.
Related
I tried to use a OneDrive folder to store my Flutter project [Windows 10, Android Studio]. I then made edits to it on another machine [same configurations]. The project compiled fine on the first machine initially and on the second one after the changes. Running it on the first machine again after the changes I get the below error:
Execution failed for task ':app:processDebugResources'.
Path "build/[package]/intermediaries/compiled_local_resources" is not a readable directory.
I've tried a number of solutions mentioned in similar, though not equivalent issues:
Updating Android Studio
Running Android Studio as Administrator
Removing the [package] from my dependencies (this resulted in a
different package being identified in the error message).
Pressing File -> Invalidate Caches / Restart...
Commenting out
"org.gradle.jvmargs=-Xmx1536M" in gradle.properties
Doing:
cd android
gradlew clean
None of this worked.
I had the same problem today:
Path "build/[package]/intermediaries/compiled_local_resources/debug/out" is not a readable directory.
I was able to fix this issue by deleting the .gradle and rebuilding the project.
All I did was create the (empty) directory that it was looking for and it built fine afterward.
mkdir -p compiled_local_resources/debug/out
I had the same issue, came out of no where and it really shouldn't make the build fail... but all I did was create the (empty) directory that it was looking for and it built fine afterwards.
In the end the only thing that worked for me was pushing the project up to a Git remote and cloning it from there into another (local) directory.
[not sure this counts as a solution but nothing else worked for me after a long agonising search so hopefully it helps someone]
I know the OP had Windows, but if it helps anyone else in the future:
On Mac OS I discovered (the hard way) that Android Studio and Flutter do not play nice with being stored in iCloud! I noticed that some files weren't available locally and that's what was causing the problem for me. I moved my project out of iCloud (forcing it to download the missing files forever) and then it was fine.
Deleting the android/.gradle folder worked for me.
+1 also to the #1 answer (Vadow). As I do not have 50 points yet was not able to add this as a comment, so will have to post separately.
Like the OP, I have two machines - and got into trouble (Synology Drive). Vadow's solution worked for me, but I also had to do:
Flutter Clean
Flutter Pub Get
on the terminal and from within the project directory to get things follow back up and running.
Thank you Stackoverflow, and thank you Vadow!
When I tried to upgrade my working copy on my linux server - I am getting the error
Can't upgrade '/var/www/vhosts/xx.xx.xx.xx/abc/xx/yy/zz/Command' as it is not a pre-1.7 working copy root, the root is '/var/www/vhosts/xx.xx.xx.xx/abc'
Do I need to upgrade from root itself?
I am not sure if I upgrade it from root, my updated and modified files will be safe?
Note - I am using svn upgrade command.
Yes, your working copy must be upgraded at the root of the working copy. Otherwise, the WC would be left in a very inconsistent state. Consider how a client would be expected to attempt to deal with a WC that consists of mixed format changes.
I recommend that people commit all changes prior to upgrading to to be safe, but you will probably be OK to upgrade from where you are now. If it hoses the WC, check out a new one & copy your changes over.
I created a git repo in Windows 7 on a NTFS partition and when opening it in Linux (Ubuntu 12 x64, dual-boot setup) I get the index file open failed error. How can I figure out what's wrong? The partition is mounted read-write and I've never had any other problems. Does git store data in a different format Windows vs. Linux and I need to do either a clone or some conversion? I'd really like to be able to work on the same repo in both OSs without cloning around...
Clarification: I also get cat: index: Input/output error
when running the command cat index in the .git dir, so it is a NTFS related problem... but I've never had it before untill using git in a cross-systems way and I've run other apps from NTFS parts and copied files around...
The .git/index file is a binary file, which describes the current workdir. Perhaps a git fsck is able to fix it up (move the one you have out of the way to make sure it isn't lost while you fool around, or make any expertiments on a copy of the repository). You might try to clone the repository locally, the clone might get a good copy of the file, which you could then copy over the broken one.
Possibly permission problems? Backup what is relevant, defragment the drive, run hardware checks (it might be a broken/breaking disk!).
Either your Linux NTFS driver is broken, or you have filesystem corruption, or both. Reboot to Windows and run the disk checking utility, then see how things stand when it finishes.
Svn update is not working completely.some updates are coming and after that some error occur.like 403 forbidden error.Now i need to get inside each folder and have to update separately.Can anyone tell me what may be the problem and what i have to do? I am using tortoise svn.
Also svn itself prompting that perform clean up.But when i try to clean up.Clean up not working properly messge is showing..
problem is fixed when svn upgraded to next version
Everytime I try to commit files to SVN I got the following error.
Command Commit
Modified D:\Project\src\WebSite\SomePage.aspx.cs
Sending Content D:\Project\AKent\src\WebSite\Test\SomePage.aspx.cs
Commit succeeded, but other errors follow:
Error bumping revisions post-commit (details follow):
Can't set file 'D:\Project\AKent\src\WebSite\Test\SomePage.aspx.cs'
read-write: Access is denied.
After I get this error, SVN doesnt allow me to update or commit anything! And what is really frustrating me is that the project folder is around 2 GB and every night I download it from SVN over and over.
Please help me to fix it! I just wanna know what is wrong with my SVN. I tried reinstalling, didn't fix anything.
I had the same problem but fixed. My solution is:
1. Run Command Prompt as Administrator
2. Navigate to the target working copy
3. svn cleanup
The error
read-write: Access is denied.
indicates that svn can not access the file or can't set all attributes it needs to that file.
Now that either means you have not full access to those files or some other application has the file opened exclusively.
In the first case: make sure that your username has full access to all folders and subfolders of your working copy. Note that on Vista/Win7 it's not enough to be an admin - you have to give yourself full access to such files manually.k
In the second case: disable windows search indexer for your working copy, and exclude the working copy from being scanned by your virus scanner.
If you are sharing a svn versioned folder using samba and running into this issue when acessing it from windows machine, try:
http://tortoisesvn.net/faq.html#samba
Also add to your smb.conf file:
dos filemode = yes
copy the wrong folder (1) to another folder(2)
delete the wrong folder (1)
copy the backup(2) to (1)
Hope this approach works for you too!
I was trying to revert a file but was receiving the error listed in the OP's post. Soony's answer just about worked for me. I cannot comment or edit that answer, so I had to copy their answer and add a small step at the end. S/he deserves all the credit.
Run Command Prompt as Administrator
Navigate to the target working
copy svn cleanup
svn revert [filename]
(the revert did not work in Windows Explorer/TortoiseSVN integrated tools, I had to do it from the cmd line)