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.
Related
We just switched to Mercurial from SVN. I have some local properties file like jdbc.properties that refers to my local database and is never checked into repository. When I try to pull files Mercurial complains there are uncommited files. How to best deal with this situation
Regards
If you never want to commit jdbc.properties to your repository, you should ignore it.
Check out the link for more information - in short, you'll have to create a text file called .hgignore in your working directory, and input the files names of the files you want to ignore.
Then, you'll never see the files again when you try to commit, and Mercurial won't complain about uncommitted files anymore.
If the application won't work without the config file and you want some version of it in the repository, you might not want to ignore it.
Because if you do, you can't just clone the repository and start your app - it will complain about the missing config file.
Plus, you probably want to have your configuration files under source control as well - just without "secret" data like usernames and passwords.
Maybe this approach is something for you then.
The example shown there is in MS Visual Studio (because that's what I'm using), but you can something similar in any other stack.
Is there any built in mechanism for editing a repository's hgrc config file using the Mercurial API? I'm writing an extension that requires storing some options in the config file, and I'd like to provide a command for do so (the options that need to be stored involve timestamps and would be a little tricky for users to edit manually).
The Mercurial codebase does not provide any automated way to edit hgrc files except when they're first created by a clone operation and then only to set the paths.default setting to the origin.
I version controlled a project settings folder a couple months back on my default branch, and then over time created many branches off default. Now I've decided that I'd rather not have the project settings folder version controlled as it creates a lot of problems when switching between branches.
So I've hg forget'd this project settings folder which lets me keep the files on my local machine but removes them mercurial. However, when switching from one of the old branches which still have this folder versioned back to the default branch it actually removes the files from the local machine, which is bad.
How do I prevent that?
The folder is also in .hgignore on default now.
It's impossible to do.
But the common practice is to keep config.ini.dist in your repository and build environment-specific config by some build-system right after you check source code out.
The standard way to deal with this is to version control a template config file and ignore the real config file. The real config file can then include the template file, or maybe the template file is copied over once in a while.
The underlying reason for your problems is that running:
$ hg forget config.ini
is exactly the same as running:
$ hg remove config.ini
$ hg cat config.ini > config.ini
The forget command leaves the file behind in your working directory, but what you commit is still a file removal. This means that afterwards, Mercurial cannot distinguish between "file was forgotten" and "file was removed" — only the removal is committed, so the two commands look exactly the same.
I have a project using mercurial for version control, SCons to build, and google test to write unit tests. The hgrc file hooks pre-commit and runs SCons to build the project and and run unit tests. Is there a way to "check-in" a portion of the hgrc file so that newly checked out copies, and any merges with my version of the project automatically get an hgrc file that runs SCons when they try to commit?
You can't get people to automatically have entries in their .hg/hgrc when they clone -- doing so would make it possible for someone to put rm -rf ~ in a commit hook, and wouldn't that be a bummer for the erstwhile cloners.
What you can do is include a file named something like mandatory.hgrc outside of the 'hg directory and then tell cloners to put this line in their .hg/hgrc:
%include ../mandatory.hgrc
Though that's still showing an awful lot of trust in you.
If you control the machines, as in many corporate settings, you can have your package/deployment/update tools (we use puppet) put whatever you want in their /etc/mercurial/hgrc file.
You cannot checking anything under the .hg folder. What my team does it that we have a common mercurial.ini file which as part of the dev box setup we put in our user profile folders.
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.