I have Master/Slave setup using Win2k8R with SVN 1.6.9 and using TortoiseSVN 1.6.7.
The access is through Apache and using http.
Everything works but when I commit I get the following message:
Error: post-commit hook failed (exit code 1) with output:
Error: The process cannot access the file because it is being used by another process.
This happen when using multiple TortoiseSVN dialog for committing the files in rapid succession. If I use one TortoiseSVN dialog and wait till the commit reply is back then I won't see the problem. In other words, committing one at the time cause no issue.
The post-commit script output is logged.
Even though I get the above error but when I check the Master and Slave repository the files have been replicated okay with no issue.
I am wondering how this issue can be solved.
You should vote this as an issue in the Subversion Issue Tracker.
Related
I'm using Hyperledger Fabric and now I'm trying to make a backup of the current situation and restore it on a different computer.
I'm following the procedure found in hyperledger-fabric-backup-and-restore.
The main steps being:
Copy the crypto-config and the channel-artifacts directory
Copy the content of all peers and orderer containers
Modify the docker-compose.yaml to link containers volumes to the local directory where I have the backup copy.
Yet it's not working properly in my case: when I restart the network with ./byfn.hs up I first have all the containers correctly up and running then, whatever operation I try and execute on the channel (peer channel create, peer channel join, peer channel update) fails with error:
Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'mychannel': error authorizing update: error validating ReadSet: proposed update requires that key [Group] /Channel/Application be at version 0, but it is currently at version 1
Is there anything I should do which is not mentioned on hyperledger-fabric-backup-and-restore ?
I got the same error while trying to create a channel. Turning the "network down" and then "network up" solved my problem.
Since this morning, when I try to sync from GitHub Desktop after creating a commit, I sometimes get the message:
When I try to push the commit in Git Shell, I get:
SSL read: error:00000000:lib(0):func(0):reason(0), errno 10054
What could be the issue?
It takes around one or two minute between the time I try to push and the time I get the error message (in GitHub Desktop or Git Shell), so I suspect some connection issues on GitHub side (I have checked the robustness of the connection on my side), but I find the message sibylline.
I use GitHub Desktop with Windows 7 SP1 x64 Ultimate.
Change URL from https to http, for me it worked. There must be problem with ssl tunnel. But currently you can start it by switching to http.
I got here because I was looking for a solution, too. I have got an SSL read: error.... (identical to yours) returned as well when I was trying to push a commit. The reason might have been some big files in the commit that you were trying to push to github.
For me, I followed steps https://git-lfs.github.com provides and it seems to solve my problem.
A lot of people have ask this question but it was 2 month ago with another gitlab version,
I'm using gitlab 5.2 in a fresh debian 7.0 serveur
everything looks Okay on the website but when I run /home/git/gitlab-shell/bin/check I've got this error :
Check GitLab API access: FAILED. code: 302
Check directories and files:
/home/git/repositories: OK
/home/git/.ssh/authorized_keys: OK:
I'm running on a custum ssh port but I'm able to connect.
When pushing I've got this error:
git push -vu origin master
Pushing to ssh://git#apps.ndd.fr:2232/Users/test.git
fatal: The remote end hung up unexpectedly
Thanks for your answers!
I've just got the same error and go look onto the code.
The thing I've found the gitlab_net module going for answer at #{host}/check (gitlab-shell/lib/gitlab_net.rb)
host method is defined as "#{config.gitlab_url}/api/v3/internal", and at the same time config.gitlab_url defined in ./gitlab-shell/config.yml "Should end with a slash" (c) So my web server just returns 302 on a request to remove double slashes.
FYI: That fail is about API and not about web service. So it's non-critical in many cases anyway.
I think it's a minor bug in code and there is a close issue to this: https://github.com/gitlabhq/gitlabhq/issues/3483
We have recently upgraded from WebLogic Portal 9.2.3 to 10.3.5. We have a JackRabbit repository connected through the Day Software JSR-170 VCR-JCR provider. This has all worked perfectly fine on 9.2.3, but on 10.3.5 we are getting a IllegalMonitorStateException when we try to retrieve content. We have out own facade on top of JackRabbit, that implements the JCR-170. Here is the debug out from the server:
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.initializeSessionState():1215] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2b70161: (re)initializing all repo sessions for username: <WLS Kernel>
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.initializeSessionState():1215] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2bf2311: (re)initializing all repo sessions for username: <WLS Kernel>
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.initializeSessionState():1215] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: (re)initializing all repo sessions for username: <anonymous>
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.ensureConnectedToRepository():801] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: no session found for repoName=indhold; need to connect
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.ensureConnectedToRepository():821] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: connect write lock acquired for repoName=indhold
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.connectToRepository():875] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: connecting to repositoryName= indhold
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.getRepositoryClass():1503] invoking Class.forName(repoClassName)
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.getRepository():1403] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: Ticket authentication error for: indhold java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:363)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1317)
at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:745)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.getRepositoryClass(RepositoryManagerDelegate.java:1537)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.getRepository(RepositoryManagerDelegate.java:1327)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.connectToRepository(RepositoryManagerDelegate.java:893)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.ensureConnectedToRepository(RepositoryManagerDelegate.java:832)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.connect(RepositoryManagerDelegate.java:1160)
at com.bea.content.federated.internal.delegate.RepositoryHelper.checkCapability(RepositoryHelper.java:759)
at com.bea.content.federated.internal.CapabilityManagerImpl.checkRepositoryCapability(CapabilityManagerImpl.java:57)
at com.bea.content.federated.internal.ManagerImplCapabilityHelper.checkCapability(ManagerImplCapabilityHelper.java:80)
at com.bea.content.federated.internal.ManagerImplCapabilityHelper.verifyCapability(ManagerImplCapabilityHelper.java:54)
at com.bea.content.federated.internal.NodeManagerImpl.getNode(NodeManagerImpl.java:432)
at dk.skat.portal.front.helper.ContentHelper.getNode(ContentHelper.java:1591)
It seems that authenticationn fails, but if I try to set a break-point in the login methods in the repository (our Facade, which doesn't do any authentication challenge, but just wraps JackRabbit, and logs in the same user - "default" - for all access), we are never getting called. Setting the username and password on the Manage Repositories page, doesn't seem to have any effect.
If I on the other hand go to Portal Administration Console, and try to manage or browse the repository, everything works fine, and the login methods are actually called, and the server connects fine to the repository.
This seems very strange. In cetain cases (that happens to happen randomly, we can get the server to all of a sudden get to the repository, but on restart of the server, it is again back to failing).
I've tried to set username/password for the repository to the weblogic user, but that doesn't seem to have any effect, I still get the error.
Furthermore when I've been into the PAC, and logs out, closes the browser, reopen the browser or a completely different browser, the entering of PAC seems to activate the repository to become online (though this is not stable or desired).
Please advice, if there is a bug in WebLogic (it seems it tries to unlock() the ReadLock too many times, resulting in the mentioned exception - should it at all fail on that exception??, Should the lock-count be checked before unlocking?), or if w are doing anything wrong? I can read that there is a known bug in the eclipse tooling for 10.3.5 about exactly this error.
Furthermore, we didn't seem to have any trouble in 9.2.3, what changed in 10.3.5?
Had same issue, found solution here https://forums.oracle.com/forums/thread.jspa?messageID=10984645
In short, it is a product bug, request following patch from Oracle:
WLP Version: 10.3.5
Patch Name/Patch Number/Bug Number: 14377862
Smart Update Patch ID: HPV8
I am getting a 404 error when trying to push my database to Heroku via Taps
(1.9.2#[app_name]_db) heroku db:push --app [app_name]
Loaded Taps v0.3.24
Auto-detected local database: sqlite://db/development.sqlite3
Warning: Data in the app '[app-name]' will be overwritten and will not be recoverable.
! WARNING: Destructive Action
! This command will affect the app: [app-name]
! To proceed, type "[app-name]" or re-run this command with --confirm [app-name]
> [app-name]
Sending schema
Schema: 0% | | ETA: --:--:--
Saving session to push_201209251425.dat..
!!! Caught Server Exception
HTTP CODE: 404
The db:push command used to work fine, then I made some changes to my database by rolling back the migrations, editing them, and then re-migrating. Now I can deploy the app just fine, but the database will not push -- I don't know if this is related to editing the migrations or not.
The app works fine on my machine, and I wanted to eliminate any discrepancies between Heroku's copy and my own, so I created a new app and pushed to that. Same thing: the Heroku app works but will not receive db:push; it errors out with the same 404 above.
Is this a Heroku service temporarily down, or has changing my app caused the 404?
Edit: heroku logs do not show any error message
Heroku support was taking too long to respond, so I found a workaround that communicates with my EC2 instance directly by using the Taps gem.
Go to Heroku dashboard for your database. For me this was at
https://postgres.heroku.com/databases/[my-database-name]
though I navigated by going through Addons.
Click on 'URL' in 'Connection Settings', should give you something like
postgres://[username]:[password]#ec2-[ip_address_numbers].compute-1.amazonaws.com:[port]/[database_name]
Copy this value down, I'll reference it here as [EC2_URL]
Get Taps installed on 1.9.2 gemset if you don't already have it (not sure if 1.9.3 will work, didn't test it)
Set up localhost taps server to facilitate transaction by running in terminal:
taps server postgres://[local_machine_username]#localhost/[name_from_database.yml] [some_username] [some_password]
(note the spaces before username and password)
Then you can process the transaction yourself through another terminal window:
taps pull [EC2_URL] http://[some_username]:[some_password]#localhost:5000
It should run and pull all your data from the local development db to the Amazon instance. You can also do vice versa, or choose a different database, etc. Or not, I'm not a cop.
There are some problems with heroku db commands and ruby 1.9.2 (I have this version).
db:pull ends with "Unable to fetch tables information from"
db:push ends with "!!! Caught Server Exception HTTP CODE: 404"
There is a work-around for this problem. Switch to ruby 1.8.7 (I am using rvm for this) for a moment just to do db operations on heroku and after finish switch ruby back.
I do the same process (have Heroku convert my sqlite database to Postgres), and I was getting this problem yesterday as well. It seems to be working now, so I'm believe it was an issue with Heroku.