I have been trying to use HG convert to migrate a local CVS repository to HG. When I run the command...
hg convert CATools
I see the following message:
"Valid-requests", but got '')
"Valid-requests", but got '')> assuming destination CATools-hg
initializing destination CATools-hg
repository connecting to
:sspi:shcgl-egcrizan:2401:/cvsroot
Unknown command: `server'
CVS commands are:
add Add a new file/directory to the repository
admin Administration front end for rcs
annotate Show last revision where each line was modified
checkout Checkout sources for editing
commit Check files into the repository
diff Show differences between revisions
edit Get ready to edit a watched file
editors See who is editing a watched file
export Export sources from CVS, similar to checkout
history Show repository access history
import Import sources into CVS, using vendor branches
init Create a CVS repository if it doesn't exist
log Print out history information for files
login Prompt for password for authenticating server
logout Removes entry in .cvspass for remote repository
rannotate Show last revision where each line of module was
modified
rdiff Create 'patch' format diffs between releases
release Indicate that a Module is no longer in use
remove Remove an entry from the repository
rlog Print out history information for a module
rtag Add a symbolic tag to a module
status Display status information on checked out files
tag Add a symbolic tag to checked out version of files
unedit Undo an edit command
update Bring work tree in sync with repository
version Show current CVS version(s)
watch Set watches
watchers See who is watching a file (Specify the --help
option for a list of other help
options) abort: unexpected response
from CVS server (expected
"Valid-requests", but got '')"Valid-requests", but got '')
Has anybody found a workaround? I found this article but do not understand how to do this on Windows.
http://blog.edsantiago.com/archives/2009/02/19/#e2009-02-19T19_23_32.txt
Please consider using cvs2hg for the conversion. "hg convert" is known to have problems with nontrivial CVS repositories, for example often silently producing a Mercurial repository whose branch/tag contents do not agree with those in the CVS repository. Unless you require incremental conversion (and can live with inaccuracies), "hg convert" is not a reliable solution for converting from CVS to Mercurial.
How "local" is local? If you have filesystem access to the CVS repository, you can just copy it over and do a real local hg convert.
Related
I use Tortoise 2.7.1 on a Windows 8.1 machine
I'm trying to push my project to the common repository (Windows Server 2003 R2) and it's aborting with the following message:
abort: empty or missing revlog for image/Thumbs.db
I must add that I recently disabled the creation of Thumbs.db and started to delete the existing ones.
After I got this error, I tried to add Thumbs.db to .hgignore and commit + push. As before, commit was good, but push still gave me the same message.
Any help would be highly appreciated.
Thanks,
Setnara
I had the same problem and solved it in this way:
remove the file ( image/Thumbs.db, in your case) from the disk
in Hg, "forget" for the file ( image/Thumbs.db )
in Hg, "commit"
added the file ( image/Thumbs.db ) again in the directory
in Hg, added the file
in Hg, "commit"
started to delete the existing ones
It looks like you also deleted (probably recursively) some files in the Mercurial repositories and it is (or they are) now corrupted.. :-(
If you can find the repository on the disk, you can check its state with the following command: "hg check" (I do not know if Tortoise has such a command in the menus) and this will tell you if you have a corruption or not.
If this is the case, I'd suggest to make a backup of your files, remove the corrupted repository, and to clone it again from the central common repository, then checkout the files and compare them with the saved ones (you might have worked on some files and not committed them).
Hope it'll help.
I have just had the same problem.
If you still have the files in the trash, there is a possibility that the files in question still exist. If this is the case, you can just restore the files and push.
For example I have a hg versioned project in this path: C:\src\sample_project
Now, lets this project have subfolders, and lets say I'm editing a file inside this project C:\src\sample_project\docs\index.rst.
Having the path of this file C:\src\sample_project\docs\index.rst what is the easiest and most effective way to check if the file is versioned by hg, by either using Windows shell commands, hg.exe or tortoise (thg.exe)?
I'll post my doubt as answer.
Command to check if file is versioned: hg status <path> and then if the first character in stdout of this command is ? or a (from abort: no repository found in...) I should assume that file is not versioned.
What you stated is a way, but there is a cleaner one imo. You can use:
hg status -u which lists all unknown (read: not tracked) files in your repository.
I need to control the version of a few files accessible via an SMB share. These files will be modified by several people. The files themselves are directly used by a web server.
Since these are production files I wanted to force the users to pull a local copy, edit them, commit and push them back. Unfortunately there is no Mercurial server on that machine.
What would be the appropriate way to configure Mercurial on my side so that:
the versioning (.hg directory) is kept on the share
and that the files on the share are at the latest version?
I do not have access to this server (other than via the share). If I could have a mercurial server on that machine I would have used a hook to update the files in the production directory (I am saying this just to highlight what I want to achieve - this approach is not possible as I do not control that server)
Thanks!
UPDATE: I ended up using an intermediate server (which I have control over). A hook on changegroup triggers a script which i) hg update to have fresh local files ii) copies them to the SMB share
EDIT 1 Following discussions in comments with alex I have looked at the verbose version of the command line output. The \\srv\hg\test1 repo has a [hooks] section with changegroup = hg update. The output from a hg push -v gives some insights:
pushing to \\srv\hg\test1
query 1; heads
(...)
updating the branch cache
running hook changegroup: hg update
'\\srv\hg\test1'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
abort: no repository found in 'C:\Windows' (.hg not found)!
warning: changegroup hook exited with status 255
checking for updated bookmarks
listing keys for "bookmarks"
If I understand correctly the output above:
a cmd.exe was triggered on the client, even though the [hook] was on the receiving server
it tried to update the remote repo
... but failed because UNC are not supported
So alex's answer was correct - it just does not work (yet?) on MS Windows. (Alex please correct me in the comments if I am wrong)
If I understood correctly, you are looking for two things:
A repository hook that will automatically update the production repo to the latest version whenever someone pushes to it. This is simple: You're looking for the answer to this question.
If you can rely on your co-workers to always go through the pull-commit-push process, you're done. If that's not the case, you need a way to prevent people from modifying the production files in place and never committing them.
Unfortunately, I don't think you can selectively withhold write permissions to the checked-out files (but not to the repo) on an SMB share. But you could discourage direct modification by making the location of the files less obvious. Perhaps you could direct people to a second repository, configured so that everything pushed to it is immediately pushed on to the production repository. This repo need not have a checked-out version of the files at all (create it with hg clone -U, or do an hg update -r 0 afterwards), eliminating the temptation to bypass mercurial.
What prevents you from mount your Samba share and run hg init there? You don't need mercurial server (hg serve or more sophisticated things) to perform push/pull operations.
I'm using the Mercurial Convert extension to import data from a PerForce repository. The conversion appears to have worked correctly, but all the Windows line endings (CRLF) were replaced by unix endings (LF).
Is there a way to get this extension to leave the line endings alone?
While the conversion itself may change the eol style, you still can, in your new Hg repo, specify what eol you want to see for certain types of files on checkout:
See EolExtension.
When working with people on different operating systems, it can therefore be desirable to be able to checkout text files with the operating system native line ending representation.
This extension lets you specify how end of lines (EOLs) are converted between the repository representation and the working copy representation.
I was able to do what I wanted using the "Perfarce" extension for Mercurial. The line endings for the mercurial repository will follow the settings of the "LineEnd" property of the Perforce workspace you are using. The steps were the following (on Windows):
Clone the Perfarce repository (https://www.mercurial-scm.org/wiki/PerfarceExtension)
In the mercurial.ini file of your user folder, add the configuration information described https://www.mercurial-scm.org/wiki/PerfarceExtension
Create a Perforce workspace that maps desired parts of the Perforce repository to the root folder for the workspace on the local computer
Update the local workspace
Open a command line at the parent folder of the desired mercurial repository folder
set P4PASSWD=your_perforce_password
set P4USER=your_perforce_username
hg clone p4://perforce_server_ip:perforce_server_port/your_perforce_workspace_name destination_folder
The resulting hgrc file for this repository is set up to pull additional changes from the Perforce repository, so it could conceivably be used on an ongoing basis, but I didn't use that.
I created a repository on a remote machine using:
hg init
hg add
hg commit
The repository was created.
I cloned the repository on a local machine with no errors reported; The files seem to be there
Now I'm trying to make a clone of the clone (as a working copy) using:
hg clone "path to original clone"
It returns:
destination directory: "name of repository"
abort: No such file or directory: "path to original clone"/.hg/store/lock
What am I doing wrong?
Thanks
What filesystem is used on the partition where the main repository is ?
Actually, when Mercurial is doing some operations, it needs to lock the repository. For doing this it creates a symbolic link to an nonexistent file, when the filesystem supports it, in the .hg repository, telling every other processes that the repository can't be modified at this time. When symbolic links aren't supported by the filesystem, a normal file is created.
However, there's some problems with some FUSE filesystems, typically SSHFS with the follow_symlinks option activated. FUSE reports that he knows about symbolic links, but since SSHFS follows the symbolic link and the file doesn't exist, the "state" of the link is marked as unknown thus Mercurial thinks the repository isn't correctly locked and abort the operation.
I see you're using Cygwin, so maybe it's the same kind of problem with tools designed for UNIX on a windows filesystem. It's a strange, coworkers of mine are using Mercurial via Cygwin just fine.
I don't know if it's the case for you, but I lost nearly half a day on this problem. Maybe this answers can help some people in the future.
Please paste in the actual command that's failing and the output including the actual path to the clone that you're cloning. When you do the clone use --debug and --traceback too.
As a workaround you can can always try hg init newclone followed by hg pull -R newclone pathtooriginalclone, which is effectively equivalent except it doesn't use local hardlinks when possible.