Recently I installed Git (Using Bit bucket for repository). I configured everything according to different guides I found on the net, but whenever I use the command git push -u origin --all I get the following error:
The procedure entry point curl_multi_timeout could not be located in the dynamic link library libcurl.dll
Go to the folder where Git is installed (defalut: C:\Program Files\Git).
Copy the file "libcurl.dll" in Git installation folder (C:\Program Files\Git\bin\libcurl.dll).
Paste it in location where the git.exe exists (C:\Program Files\Git\libexec\git-core).
This should fix the issue, since now it will check for the lib in current executing folder before falling back to systems folder.
It looks like it's an OpenOffice conflict from their libcurl. From my understanding, Openoffice put an old libcurl.dll in the system directory.
Try to remove libcurl.dll from C:\Windows\sysWOW64 and/or C:\Windows\System32 (Reinstalling Git or uninstalling OpenOffice doesn't seem to fix the problem).
As a side note for anyone using pre-built libcurl in their projects: this can be caused because you have libcurl.dll in the root of the folder you are trying to push. Windows will load the library in your project folder before the one with Git first.
The solution is simple -- remove or move libcurl.dll in your project.
This is the same thing with the windows application installed in your local appdata directory.
To copy the file from :
C:\Users\YOUR-WINDOWS-COUNT\AppData\Local\GitHub\PortableGit_xxxx-A-BIG-NUMBER-XXXXXXXXXXXXX\libexec\git-core\bin\libcurl.dll
to the directory:
C:\Users\YOUR-WINDOWS-COUNT\AppData\Local\GitHub\PortableGit_xxxx-A-BIG-NUMBER-XXXXXXXXXXXXX\libexec\git-core
seems to work.
Follow these steps (this worked for my 64 bit win7):
a) Copy libcurl.dll from C:\Windows\sysWOW64\libcurl.dll
to some temporary location.
b) Remove libcurl.dll from C:\Windows\sysWOW64\libcurl.dll
c) Try cloning repository from Git Windows App.
Enjoy! :)
Remove libcurl.dll from C:\Windows
After that it worked
I was setting things up for http access. I was getting a similar error (libcurl-4.dll is missing) on the client. The fix turned out to be that some of the housekeeping files deep in the repository tree on the server were owned by 'root' rather than 'apache'. Correcting that corrected the missing curl error on the client.
For me (64 bit Windows7), uninstalling GIT and reinstalling it was the only solution that worked.
Related
recently I try to install pylucene on a server in my own home directory because I have no root priviledge.
Now I have successfully installed ant and JCC locally on CentOS under my own home directory. The directory of JCC is "/home/myname/.local/lib/python2.6/site-packages"
I have also successfully "make" under the pylucene directory, but when "make install" it shows that it tries to move some files into the directory " /usr/lib64/python2.6/site-packages/" which I have no permission to access it.
I do changed the Makefile several places as required.
In the comments it says:
PREFIX: where programs are normally installed on your system (Unix).
But there is no variable named as PREFIX
I changed
PREFIX_PYTHON=/usr
ANT=/home/myname/packages/apache-ant-1.9.7/bin/ant
PYTHON=$(PREFIX_PYTHON)/bin/python2.6
JCC=$(PYTHON) -m jcc.__main__
NUM_FILES=8
When I read the Makefile I do not see a environmental variable that controls the installing directory or I miss something ?
SOlved
Thank you guys. I have figured it out.
I just move the builded “lucene” folder directly to my local "site-packages" directory and it works.
INSTALL_OPT=--prefix <path>
The homebrew formula has an example of this.
I am new to Bitbucket. I am trying to setup my computer to access Bitbucket using the following instructions. On Step 5, I am told to add ssh = ssh -C to file ~/.hgrc. I can't seem to find the file. Has anyone done this step successfully? How do I go about it?
It seems you don't have Mercurial installed at all. Step 3 of Bitbucket tutorial gives detailed description how to install it from MacPorts.
Once you have Mercurial installed just create .hgrc manually and add your configuration.
If you have not this file - create it. But you, maybe, just can't see it - dotted files are hidden. Anyway read hg help config
I had a problem with this too, but managed to find the .hgrc file. First get all hidden files visible by downloading this software http://invisiblix.read-write.fr/
Initially I tried to find the .hgrc file with spotlight but nothing came up. Happened to spotlight "~/", then this "~/.config" folder appeared, so I went there and found .hgrc in the same directory. Somehow it's always there but just not appearing even when called for in terminal.
I have pathogen setup and working fine under Linux, but when I try to use the some configuration with gvim73 under windows it doesn't work at all. I don't get any errors but it does nothing.
Here is my dotfiles repository up on git. I've checked this out to ~/vimfiles and I added the following to _vimrc:
filetype off
call pathogen#helptags()
call pathogen#runtime_append_all_bundles()
I've tried just about everything including putting the autoload/pathogen.vim and bundles/ folders in the /vim73 directory under program files. Nothing.
Does anyone have some experience with this? I'm assuming there is something windows specific that needs to happen to make this work.
Edit: It is probably also worth noting I can run pathogen#runtime_append_all_bundles() even using tab completion so pathogen is being loaded, but my plugins are just not working.
I'm not sure it will help but here is my working configuration:
d:\soft\vim\vim73\ - gvim itself, i.e.
pathogen.vim is copied into the
d:\soft\vim\vim73\autoload\
d:\soft\vim\vimfiles\bundle - directory
for plugins
Corresponding lines from configuration file d:\soft\vim\_vimrc:
" Use pathogen to load plugins from bundle directory
filetype off
call pathogen#runtime_append_all_bundles()
call pathogen#helptags()
Also I changed pathogen#helptags because original didn't work for my paths:
dir[0 : strlen($VIM)-1] !=# $VIM has been changed to stridx(dir, "bundle") != -1
It's an old question, but I had the same issue and solution as the OP, and it has a mildly annoying origin. I was using the following script to install everything on Windows (Vista+ and run as admin if you want the mklink part to work):
cd "%UserProfile%"
rmdir vimfiles /S /Q
git clone http://github.com/brymck/dotvim.git vimfiles
del _vimrc
mklink _vimrc vimfiles\vimrc
cd vimfiles
git submodule init
git submodule update
The above is just a Windows-y version of a Vimcast on syncing your Vim preferences with GitHub and is fairly straightforward, so I figure others may be doing something similar.
Anyway, your experience may differ (and this doesn't apply to Cygwin), but when I just copied and pasted this into the terminal, git submodule update got "eaten" while git submodule init was running. I didn't figure it out initially because this had never happened to me on Linux. In short, wait until everything else has completed before running git submodule update and you should be golden. (Also, FWIW, I'm using the current version of pathogen, which was last updated September 25, 2011.)
For me renaming the .vim folder into vimfiles solved the problem for Vim 7.4.
I had some kind of issue on Windows when I used the pathogen version provided by Vim.org
However, using github pathogen head, the issue was fixed.
I think the latest release from Vim.org is from January last year, and the latest commit on github is from November.
Specifically, I had this issue with after directory:
https://github.com/tpope/vim-pathogen/issues/closed#issue/12
I know this is a long time ago, but maybe it will help someone ... I had the same issue. It wouldn't give me any errors, but no plugins would be loaded. I then RTFM and noticed that he explicitly states at the top of this page that it should go in your vimrc not gvimrc. After I changed that I had no problems.
I installed subversion on my Ubuntu server and I can use subclipse (1.6) in Eclipse Helios on Ubuntu and it works fine.
However when I try and use Subclipse (1.6) in Eclipse Helios on Windows, it doesn't work and I get errors.
In Windows when I use http://serverAddress/svn, I get an error saying folder doesn't exist and an error in the console saying:
Repository has been moved
svn: Repository moved permanently to 'http://serverAddress/svn/'; please relocate
When I use svn://serverAddress/svn, I get an issue as well.
Does anyone have any ideas?
This is not an Eclipse issue, but a SVN issue.
If you could see your repo in a web browser, the SVN FAQ mentions an httpd.conf error. But in your case:
either you haven't created a repository yet (see svnadmin create)
or you have a repo, but haven't create properly a directory in it, a bit like in this thread:
I then created a subdirectory "projectx" under ~/webapps/svn with subdirectories "trunk", "branches" etc and then ran:
$ svn import projectx file:///home/<user>/webapps/svn/projectx -m "first import".
projectx/trunk etc showed up fine on Trac, and https://svn.<user>.webfactional.com/projectx/ showed up fine in the browser, with proper authentication etc. All well and good.
However, when attempting to check out the project from trunk (using Tortoise SVN), I got this error:
Command: Checkout from https://svn.<user>.webfactional.com/projectx/trunk, revision HEAD, Fully recursive, Externals included
Error: Repository moved permanently to
Error: 'http://svn.<user>.webfactional.com/projectx/trunk/'; please relocate
With the solution being:
You've created directories on the filesystem below your repo, eg ~/webapps/svn/projectx. That's the wrong way.
You should instead use 'svn mkdir' to create the directories.
If this is not enough, see also this SO question, where it mentions that the repository address is usually http://servername/svn/repositoryname, not http://servername/svn.
Here's what I did, I have installed svnserve as a service and I started it with the net start svn service command. I typed svn ls svn://localhost to test the service but it returned the error as stated in the title of this post.
I entered svn --version and svnserve --version on my computer to find out the version numbers and the client and the server version is the same, version 1.5.6. I'm guessing the error appears due to different versions of the server and the client.
When I start the server using svnserve --daemon --root command in cmd, The error still appears.
Why does the error appear? Thanks
Which Subverson tool did you use to create the repository? TortoiseSVN? Your TortoiseSVN may be newer, a 1.6.x release, then your 1.5 command line client and svnserve, so svnserve 1.5.x cannot serve a 1.6.x repository.
In my fsfs repository created with svnadmin 1.6.1, the db/format file contains
$ cat repos/db/format
4
layout sharded 1000
I have the same problem but I had resolve it with a different approach
The issue mainly is the db/format file where it expects a "2" best way to check is to ope the file
$ vi db/format
If you get this
4
layout sharded 1000
Then you should change them to say
2
Its better to also check you current file
$ vi db/current
It you get only this (e.g. 0 meaning reviosion number 0)
0
Then you should change them to just say (e.g. 0 meaning revision number append "nx" and also "2" )
0 nx 2
Finally Check also if your directory structure for the revs and revprops is sharded or looks something like this
db/revs/0/0
change it to a non folder structure
db/revs/0
Note: the revision file (e.g. 0) is just inside the revs directory, no more other folder should be there
Same goes with revprops
change
db/revprops/0/0
to
db/revprops/0
I delete my old repository and create a new one using command line -> svnadmin create C:\SvnRepository
*old repository was created by right clicking on the folder and click "Create Repository here"
I installed (the Collabnet install of) SVN 1.5.5 and it was running fine with TortoiseSVN 1.6.1. After upgrading SVN to 1.6.2 I'm getting the same error (Expected fs format between ‘1’ and ‘3’; found format ‘4’) when I try to access it through Trac. This lends credibility to Blair's answer. I'll let you know how I get it running again.
Update: Blair's answer worked for me, too: the message says that an old version of SVN is trying to access the repository, so find it and delete it. The specifics for me were that the error only occurred when I used Trac, so I re-installed Trac on Windows (http://trac.edgewall.org/wiki/TracOnWindows) with the latest installer I could find (svn-python-1.6.1.win32-py2.5.exe) and deleted old eggs from the Python site-packages folder. After a reboot and resync, I was up and running again.
The latest version of Zend Studio (8.x) has an SVN tool which gives the same error about finding format 4, but expecting format 1-3. I had created my repository using CollabNet SVN (about a year ago) and was unable to open the repository from within Zend Studio.
I think the best solution (at least for my case where I want to work with Zend Studio and not fight with it) is to recreate your repository with the old version of SVN. The URL for SVN 1.3 for Windows is:
http://subversion.tigris.org/files/documents/15/32856/svn-1.3.2-setup.exe
After installing this, make sure you are executing the svnadmin.exe and svn.exe in the newly installed version 1.3 directory in case you have already installed CollabNet SVN (which has a default install directory of c:/csvn).
Make sure you are using the correct svnadmin. For example, if you installed VisualSVN, you will need to use the svnadmin located in the bin folder of the installation directory. I had installed the command line version of SVN...and when I used this version of the svnadmin tool, I got the same error.
Thanks, Joe. I had both CollabNet SVN server and VisualSVN installed and was getting errors until I made sure I was using the version of svnadmin that came with VisualSVN (which I had used to create the repositories).
I was able to fix this by updating Subversion on the server. I also made the adjustment on the db file. Then I pushed everything backup onto the server as an overwrite. I actually (on windows) did a checkout locally, then the files that were generated in creating that repo, I edited the db, then grabbed all files and pushed them up to SVN on the server.
That seemed to have done the trick.
well i have also faced the same problem.
just open your svn remote folder you have made.
in your db folder you have format file.
just replace the no. with 1.
if it does not work try 2, and 3.
If you are using VisualSVN server, Make sure your command looks similar as below
Sample Command:
C:\Program Files\VisualSVN Server\bin>svnadmin dump c:\repo > c:\backup\svnbacku
p.dump