I am trying to use git svn clone with cygwin 64 on a svn repository and I keep getting this message which errors out:
Temp file with moniker 'svn_delta' already in use at /usr/lib/perl5/vendor_perl/5.14/Git.pm line 1024.
How do I resolve this issue? I found this one that's related to macs, but I'm on windows. The two main answers there say:
"Change ~/.subversion/servers" I don't know where this is in Windows 7.
"a general upgrade to latest Git (1.8.5 should be out next week) and latest SVN 1.8 can help make things run smoothly" But in cygwin I'm stuck with git version 1.7.9.
I have a feeling the latter isn't a necessary step or else everyone using the git svn bridge in cygwin would be complaining like me.
The first answer I linked to in my question had the solution. I had to find the .subversion/servers file which existed in my cygwin path of ~/.subversion/servers. I also have a SilkSVN client and I changed that servers file there too. I found the path for that in this answer.
Related
So i'm pretty new to the whole windows repo cloning thing. I installed python 2.7, added the path to my windows cmd and I still cannot run any git clone commands. It shows the following output :
git clone
File "", line 1
git clone
^
I've been scouring the internet for an answer but apparently it should work if I use cmd.
Any help would be appreciated!
git clone
File "", line 1
git clone
^
I have had the same issue recently with 3.7, so I made a new username and it worked. Kind of nice, a clean new Windows profile, even though I just started using it again compared to linux. A pain though.
Make sure all other versions of Python are not installed, or at least affecting the path to the file you need the pip installs to be saved. Python can be saved in a few different locations, and some rare times it has been shown in very obscure places. Check where your file saved on your PC. Probablu C:/ then could be many paths. /Users/UnserNameHere/Windows/ProgramFiles. I would use the search bar in the good old GUI while searching under the C drive (if you have multiple HDD/SDD then pic the one used for the C drive, if nothing comes up try the other drives.
Your looking for a file PythonFoundation I can't remember the entire name, however it will have a very long name Python Foundation are in the name of the file. This is where thing are store and where the path should be sending modules, at least the correct file inside that file.
Also try doing it from other Python versions installed. If you had 3.6 and got 3.7 it doesn't mean 3.6 has been deleted. Also doesn't mean you path, is not set to 3.6 while using 3.7. Same with Python 2, most people or many have both. The pip commands vary between python versions pip3 I believe is used (getting windows and linux a little mixed up right now)
If all fails do it the old fashon way, find the mod, download it, and move it to the python file I mentioned above. The homepage for python should have a tab linking to a page, or it's on the main page, letting you know where it has been known to save. Google how to see he path Pip is taking, or how to see if pip is installed and where, and what paths are set to.
Using Cygwin on Windows 7 64 bit.
Trying to rebase msys-2.0.dll: for Git with the below command.
However I am getting the message saying its skipped because its wrong machine type.
cd /cygdrive/c/Program Files (x86)/Git/bin
$ rebase.exe -b 0x50000000 /cygdrive/c/"Program Files (x86)"/Git/bin/msys-2.0.dll
/cygdrive/c/Program Files (x86)/Git/bin/msys-2.0.dll: skipped because wrong machine type.
What does this mean? Trying to look up on Google but didn't find much information anywhere - so hoping someone in this community can help.
As mentioned here, it could be a Cygwin issue depending on your current version of Cygwin.
But you can also try the alternative without cygwin, using the latest git-for-windows:
unzip PortableGit-2.6.3-64-bit.7z.exe anywhere you want
add to your %PATH% the folders C:\path\to\PortableGit-2.6.3-64-bit\bin and C:\path\to\PortableGit-2.6.3-64-bit\usr\bin (that last path comes with 200+ Linux gnu commands: ls, xargs, awk,... all accessible from your CMD.exe session!)
Then try again your git commands.
On Git Bash's download site, it says you can clone it to update it. I downloaded it to install it, but I am starting to really get into Git and would like to clone it every time I want to update it from now on. I think I found the place where we need to clone it to, after much searching & less documentation than usual. If I am right, it is in the home directory, right under my nose the whole time!
I checked the version number with git --version beforehand, then cloned in that directory, then rechecked the version number Both times it said git version 1.8.3.msysgit.0, but on the download site it says the latest version is 1.8.4.3.
Have I not found the elusive git folder, or does the Git Bash team not let you directly clone the latest version until some time after it comes out? I know VirtualBox does that, for example.
I know this is sort of a duplicate of this question, but I tried its answer & the PATH variable didn't even have Git!
I would recommend to not try to update it, but simply download the portable version of msysgit and unzip it in a dedicated folder, that you then add to your path:
Current Portable msysgit download.
=> I unzip the latest one in (for instance) C:\prgs\git\PortableGit-1.8.4-preview20130916.
=> I add 'c:\prgs\git\PortableGit-1.8.4-preview20130916\bin' to my PATH.
Now if you want to automate that download/update process, I am building a Powershell script which does just that (for git and 30 other programs, including Mercurial, Subversion, but also Python, Ruby, Go, ...):
senv: download the zip archive of senv, unzip it in a path and call:
senv
The first time, you specify where you want all those programs to be downloaded: those are portable software only: no registry modification, no system variables modified.
If you don't want one of those program anymore, simply delete their installation folder.
That's it.
But each time you will call senv -u, it will check their respective web page and, if a new version is detected, it will download/upzip said new version in its dedicated folder, without removing the previous one.
I am trying to run git from the command line on my Windows 7, 64 bit machine. It works fine for the most part. I tried pushing my local changes up to my private repository in the cloud.
The command I am trying to run is git push origin master
I use Cygwin 6.1 and it is causing the following error. Presumably related to the fact that I am running on a 64 bit machine
0 [main] git-remote-http 6168 fork: child -1 - died waiting for longjmp before initialization, retry 10, exit code 0xC0000135, errno 11 error: cannot fork() for send-pack: Resource temporarily unavailable
I followed the suggestions here to update my rebaseall file and reran the rebase command. But it didn't really seem to have helped.
Can anyone else reproduce the problem or have found a solution?
Thanks in advance for the help.
The Cygwin mantra I used is "fork failures are rebase issues". longjmp is not the issue, fork is. Rebase is the only solution unfortunately. In the past I have used custom scripts to build the rebase list. I do this because you may be missing some DLLs, especially if you have hand-built stuff. You can build a list with find and then pass it in to rebaseall with -T. You should also consider trying a different base address other than the default one in rebaseall, look at the -b option. 64-bit machines seem to require larger spacing than 32-bit ones and so the default didn't work well for me.
Also if you change any DLLs on your system at all, you'll need to rebase again.
Note: Even after all this fork can still fail in Cygwin. Virus scanners inject their DLLs which screw things up and Windows address space randomization doesn't help either.
The answer mfisch gave worked wonders for my problem.
A quick google search yielded this result which let me git push again in no time at all. The required packages came with the default cygwin install, so I didn't even have to install anything.
The other alternative is to use the msysgit distribution, which will allows you to make any git command without depending on the cygwin environment.
See also "Difference between msysgit and 'cygwin + git'?".
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