SVN commit txn-current-lock on Mountain Lion - iphone

I have facing SVN problem in Mac OS X ..
When i am commit any file below are the error are generate.
svn: Commit failed (details follow):
svn: Can't get exclusive lock on file '/Volumes/SvnProject/db/txn-current-lock': Operation not supported

On the SVN server, ensure that the owner and group of the repository (and all subfolders) are properly set.
For example, I created a repo by issuing the following from the SVN server as root:
svnadmin create /path/myrepo
Initially I was getting the txn-current-lock error from my SVN client. On the SVN server, I noticed that /path/myrepo and all of its subfolders had owner:group of root:root. To fix this, I issued the following from the SVN server:
chown -R newowner:newgroup
Ensure your newowner and newgroup items match the owner/group information being supplied by the SVN clients.
Important to make it recursive with the -R option. This fixed the txn-current-lock error.

Related

Error 500 checking out from github with svn

I try to checkout my repository user/bar on GitHub using the cli-version of svn. This fails with error 500.
Note: Similar questions have been asked before, but are either slightly different or have (for my case) unsatisfying answers:
Error Connecting to GitHub from SVN got a different error message
git svn gives 500 internal server error got the same error, but only with git svn clone not with native svn
Subversion Unexpected server error 500 on checkout had exactly the same problem, but it seemed to have been a temporary problem on GitHub
Community Forum describes exactly the same problem, but got no response
GitHub Documentation says: make an empty checkout of the repository,
$ svn co --depth empty https://github.com/user/repo
> Checked out revision 1.
$ cd repo
So I tried to check out my repositories of foo (created months ago) and bar (created recently), and - as a cross check - a non-existing repository baz:
$ svn co --depth empty https://github.com/user/foo
Checked out revision 4949.
$ svn co --depth empty https://github.com/user/bar
svn: E170013: Unable to connect to a repository at URL 'https://github.com/user/bar'
svn: E175002: Unexpected server error 500 'Internal Server Error' on '/user/bar'
$ svn co --depth empty https://github.com/user/baz
Authentication realm: <https://github.com:443> GitHub
Password for 'user': ****************************************
svn: E170013: Unable to connect to a repository at URL 'https://github.com/user/baz'
svn: E160013: '/user/baz' path not found
Findings:
basically it works, otherwise foo would not be fine
bar exists, otherwise the error would would be like baz
A temporary problem seems unlikely (becaus foo works), but to be sure I've waited for a couple of days - no change. Configuration of foo and bar is identical (to the best of my knowledge).
Any more ideas?
More than a week after the original attempt it suddenly works as expected. So if you happen to run into the same problem:
it might affect only selected repositories
the temporary failure might last for quite some time

Commit failed: "Repository UUID '...' doesn't match expected UUID '...'" when committing to Google Code from Eclipse on Windows

I was able to work with all my projects on Google Code just fine, but now I can't commit to any of them. I get the error:
Some of selected resources were not committed. svn: Commit failed
(details follow): svn: Repository UUID
'2b3ccc6c-acbf-642b-775e-b44874e3cfdd' doesn't match expected UUID
'2b06ef8f-344e-f67a-312d-ecb7346c3921'
(I am using Eclipse on Windows)
The same error occurs when I update.
You can fix this by correcting the UUID of the repository in the local SQLite3 subversion database. To do that, download sqlite3 from here:
http://www.sqlite.org/download.html
And put it somewhere on PATH so that the system knows about it. Then open the command prompt or your terminal (if you're on linux) in the directory that contains the repository .svn directory. Then open the subversion database file for editing like this:
sqlite3 .svn/wc.db
This will start a command a command line accepting SQL commands. Type in this command, replacing the UUID with the one that shows in your error message:
update REPOSITORY set uuid="2b3ccc6c-acbf-642b-775e-b44874e3cfdd" where id=1
Hit enter and CTRL+C to quit. Now you should be able to run your svn commit command again.
Your Working Copy is linked to Repository, which must have unique Identificator (UUID), which stored as a part of metadata in Working Copy and identity of stored UUID and contacted Repo's UUID is tested on operations, which can modify repository
For some reason, you try to communicate not to the same repository, from which your WC was created (same URL != same Repo)
Verify current UUIDs with svn info WC-PATH and svn info REPO-URL (REPO-URL for main repo and all "foreign", if externals used)
Repository UUID value must be the same
I just had this problem when I tried to commit two files at once that belonged to separate external repositories. I tried committing them separately and succeeded.

Subversion commit failed - but my credentials are correct

My problem is very similar to: svn: MKACTIVITY 403 Forbidden
My error message is as follows (the spacing is awkward, but that's how it looks in Eclipse):
svn: Commit failed (details follow):
svn: Commit failed (details follow):
svn: MKACTIVITY of '/svnroot/...': 403 Forbidden (https://repository.url)
My Software:
Linux OS with KDE user interface,
SpringSource Tool Suite version 2.9.1,
Subclipse version 1.6.10
What I've tried:
Close Eclipse. Delete the .keyring file in the Eclipse's 'configuration/org.eclipse.core.runtime' directory (to reset any stored credentials).
Modifying '/home/[user_name]/.subversion/servers' to have the password stored.
It turns out that OnResolve (from the comments on the original post) was correct. I spoke to the owner of /svnroot/ and I needed to register an account before being able to commit.
I resolved this, the issue is with old credentials which are stored in the below foldes \Users\AppData\Roaming\Subversion\auth\svn.simple
Just took back up of files from this folder and delete all and try committing again, SVN or Subclipse will prompt username and password and provide it and done, it will commit.

Subclipse on a Mac in a Windows network. Can't Commit - Can't get exclusive lock

I have an iMac running OS X 10.7.3. I have Eclipse Indigo and Subclipse 1.8.6 installed. I'm able to connect to and save files to our repository through Finder when I provide proper credentials. I am able even to check out projects. When I make changes to the checked out project, I see the update icon, I can even view conflicts in diff.
The problem occurs when I try to commit code, I am unable to get an exclusive lock, and the commit fails.
org.apache.subversion.javahl.ClientException: svn: E204899: Commit failed (details follow):
svn: E204899: Can't get exclusive lock on file '/Volumes/TECHSUPPORT/SOFTWARE/Java_Projects/db/txn-current-lock': Operation not supported
org.apache.subversion.javahl.ClientException: svn: E204899: Commit failed (details follow):
svn: E204899: Can't get exclusive lock on file '/Volumes/TECHSUPPORT/SOFTWARE/Java_Projects/db/txn-current-lock': Operation not supported
I've tried everything I can think of, I've used both available SVN's. There doesn't seem to be much on the issue.
Thanks.
What version of subversion is installed on your Mac?
$ svn --version
I think you need to update the program: SVN upgrade working copy

Mercurial abort: index ... is corrupted

I get the following error when trying to clone from the production repo.
abort: index data/HR3/globals.php.i is corrupted!
After which mercurial promptly farts out on me and fails to clone. I've tried removing the file in question from the production repo, and that failed. I also tried deleting the .hg directory in the production repo and re-adding and committing all of the files. This produces the same error.
Just fyi, I'm trying to clone the current production copy of our app to our test server. Our test server is running in Virtual Box.
UPDATE
I fixed the issue by deleting the globals file and then deleting the .hg directory and re-running "hg init" and "hg add ." and "hg commit."
Now I get an Internal server error when I try to clone. The following is the clone command I used.
sudo hg clone http://10.1.1.25/ www
Oddly enough, mercurial tells me that the "real" url is "10.1.1.25/HR3/index.php" which is most definitely not my mercurial repository. I do not know why it is doing this. I checked in my server logs, and the following error is what Apache crapped out.
[Thu Dec 16 12:25:30 2010] [error] [client 10.1.1.102] PHP Parse error: syntax error, unexpected T_STRING in /var/www/.hg/store/data/_h_r3/includes/_b_n_a_s/_b_n_a_s-_h_r_s201.php.i on line 22
Apparently the clone command is causing Mercurial to kick off PHP and make it try to parse something in Mercurial's data store?
RESOLUTION
I suspect this was caused by the fact that I have an index.php file at the root directory of my repository that does redirects. If you try and navigate directly to http:10.1.1.25 on our network, you're automatically directed to the index page, which is not the index.php page in the root directory. Somehow I think that this was causing php to kick off and try to parse items in the mercurial store. I've resolved this issue by cloning over ssh.
I have faced such an error before. Try to run
hg verify
on your corrupted repository. Then follow the instructions from here:
http://www.softwareprojects.com/resources/programming/t-how-to-fix-mercurial-corrupt-repository-1926.html
It seems that you publish your repo with the static-http method, from the same server as your development project lives. This method only works if the web server does not mess with $URL/.hg, which your one seems to do. check if you can download the .hg folder with wget -r -np $URL/.hg in a fresh folder and run hg verify there.
Oddly enough, mercurial tells me that the "real" url is "10.1.1.25/HR3/index.php" which is most definitely not my mercurial repository.
I guess that your web server redirects some mercurial requests to your index.php url.
You may try to do that:
hg forget HR3/globals.php
hg commit
hg add HR3/globals.php
hg commit