I'm trying to clone an old CVS repository with:
cvs -z3 -d:pserver:anonymous#ivan.cvs.sourceforge.net:/cvsroot/ivan co -P ivan
However, one of the directories in the repository contains a seemingly invalid character in its name, shown as � in ViewVC and as ? in the error message cvs co gives me:
cvs [checkout aborted]: cannot make directory CVS in ivan/Doc/Ty?t: No such file or directory
How can I fix this? I'm okay with excluding the directory from the checkout if renaming it isn't possible.
I solved this by running the co command twice.
On the first run, CVS stops the checkout when it encounters the directory with the invalid name. On the second run, it adds all the remaining files it didn't import on the first run (except the invalid directory).
It also complains cvs checkout: cannot remove ivan/Doc/Ty?t: No such file or directory after the second co. The directory is there, named Ty%F6t, but it's empty.
You could try using .cvsignore. You can find details here. Assuming this is what you're trying to check out, try creating a .cvsignore file with the following it.
Doc
Related
When I try to delete things from my xCode project I get this strange error does not know why. It's seems like git error but I have not created git repository in my project.
This is the error:
fatal: Unable to create '/Users/dilipmanek/.git/index.lock': File exists.
If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.
Plz help me solve this problem..
Exit XCode, go to a command prompt and type rm /Users/dilipmanek/.git/index.lock. Apparently you have a git repo of your entire home directory whether you meant to or not :)
If the git repository is there by mistake, you can go to a command prompt and type;
(always be careful with rm -r, it will remove all files under the directory given, so don't do it to your entire home directory for example)
rm -r /Users/dilipmanek/.git
...and remove the entire git repository. It will not affect any files that aren't placed in that directory, but make sure you've not copied anything you need to keep there.
The reason XCode won't delete the file is that when it finds a git repo, it will attempt to use it. Git locks files by creating a temporary file in the git directory, and if XCode crashes while doing any file operation, the file is left there and the next instance of XCode will think the repository is locked.
I'm using the following commands to convert a CVS repository to Mercurial:
cvs -d :pserver:<user>#<cvsroot> mymodule
hg convert mymodule
On an Ubuntu 12.04 machine this works, and produces a valid Mercurial repository. On a Fedora 17 machine it spends some time working, then fails with this error:
...
38000 <commit message>
37930 changeset entries
sorting...
converting...
37929 Initial Checkin.
cvs server: cvs checkout: cannot find module `mymodule/<cvsroot>/<some file>` - ignored
abort: unknown CVS response: error
Edit: I overlooked this at first, but the path that it cannot find is a little funny; it consists of the module name followed by the CVSROOT and actual path.
Both machines have identical .hgrc files and are both running CVS 1.12.13. The only environment variable that seems relevant is CVSROOT, which is the same on both machines and set to the same value as my <cvsroot> placeholder above.
The file that produces the error is the same every time, but it's a perfectly normal file; I can't identify anything that differentiates it from any other file.
Just to be clear, I know that I could simply use the working machine, and I know that there are many other tools, like cvs2svn[hg] that also do repository conversion. But I'm not interested in that; I want to understand this specific problem.
Why does conversion of the same repository fail on different machines, and what are some strategies for debugging this further?
It turned out that the Ubuntu machine had an existing checkout of that repository, which was originally checked out using a <cvsroot> specified as <server>:/<path>/. The command I used specified it as <server>/<path>/, without the colon.
CVS accepts both forms - with and without the colon - but but there's a particular function in hg convert's cvsps.py that assumes the former. If the repository was originally checked out without the colon, hg convert doesn't properly strip prefixes from filenames. This eventually results in it using the wrong path, as I noticed in the error message, when it tries to pull down file revisions.
So it worked on the Ubuntu machine because it had originally been checked out with a colon, and subsequent checkouts using the non-colon form were simply updating it without changing the contents of /CVS/Root, the file that hg convert reads to find the root.
All I had to do to get the other machine working was to rm the repository and check it out clean using a cvsroot containing a colon between the server and path.
So I'm following these instructions: http://mark-kirby.co.uk/2008/using-git-and-github-on-os-x, and so far I've cloned the project I want to work on and created a branch.
Now I wish to add files that exist in another folder on my machine, but I keep getting the following:
fatal: pathspec 'Users/mic/OnePageCRMVC/MKTsite25-05/index.html' did not match any files
However, the file definitely does exist...
Am I trying to do something that is not allowed and the error message is throwing me off?
You cannot add them automagically. You should copy the files into the git repo manually, then do a normal add/commit.
I am trying to commit a project in which a file has been "cvs remove"d, but actually needs to be there. The contents has been completely rewritten, but it needs to retain the same name.
I am unable to either commit the project or re-add the file without getting this annoying error message. How do I "unremove" a file in CVS?
This worked for me:
Rename the file
mv mistakenly_removed_file wtf
Ask cvs to add the old version:
cvs add mistakenly_removed_file
cvs then reports it has resurrected the removed file.
mv wtf mistakenly_removed_file
cvs status reveals that the file is now "locally modified"
cvs add FILE
Or, alternatively, if you want to get the latest copy back from the repository
cvs update -C FILE
When trying to commit to a cvs branch after adding a new file I get this error
Assertion failed: key != NULL, file hash.c, line 317
Any idea how to fix it so I can check my code in?
Both server and client are Linux and there are pre-commits involved.
sleep-er writes:
Not sure what the issue was but I solved it by going onto the server and deleting the file Attic/newfile.v in the repository and adding it again.
The "Attic" is the place where deleted files go in CVS. At some point in the past, someone checked in newfile.v, and at some later point it was deleted, hence moved to the Attic.
By deleting the ,v file from the repository you corrupted older commits that included the file "newfile". Do not do this.
The correct way is to restore the deleted file, then replace its content by the new file.
According to http://www.cs.indiana.edu/~machrist/notes/cvs.html
To recover a file that has been removed from the repository, you essentially need to update that file to its last revision number (before it was actually deleted). For example:
cvs update -r 1.7 deleted_file
This will recover deleted_file in your working repository. To find deleted files and their last revision number, issue cvs log at the command prompt.
Edited in reply to comment to explain what the ,v file in the Attic means.
Are you on Windows and did you rename a file to the same name with different case (e.g. MAKEFILE vs Makefile vs makefile)? CVS used to have a problem with this (and maybe still does?):
OSDir/mailarchive - Subject: Re: hash.c.312: findnode:
Manu writes:
I try to rename "makefile" to "Makefile" in my cvs tree, then:
cvs: hash.c:312: findnode: Assertion `key != ((void *)0)' failed.
cvs [server aborted]: received abort signal
CVS was never designed to cope with case insensitive file systems. It
has been patched to the point where it mostly works, but there are still
some places where it doesn't. This is one of them.
You might want to read the rest of the messages in the thread as well.
Perhaps there is some kind of pre-commit check on your repository, see here
Not sure what the issue was but I solved it by going onto the server and deleting the file Attic/newfile.v in the repository and adding it again.