Is there a way to tell Mercurial that a specified ascii file should be completely overwritten rather than merged during future updates, similar to the treatment of a binary file?
Git handles this using .gitattribues, as described here: Git mark file as binary to avoid line separator conversion. Is there a Mercurial equivalent?
Have a look at merge-patterns (in the hgrc). This allows you to specify internal:other as the merge action.
Related
I have a mercurial repo with several GB under .hg/store/data.
I identified several huge folders under .hg/store/data which start with underscore (e.g.: .hg/store/data/_some_path_example), and they are not present in the working directory.
I tried to use hg convert extension with a filemap with exclude statements, but the directories are still there in the converted repo.
What should be the paths in the exclude statements that would remove the .hg/store/data/_some_path_example paths with underscores?...
Thanks!
For the sake of other's who have the same question/issue:
As I wrote in a comment, the meaning of leading underscore is mercurial's way to specify that the letter coming after the underscore is upper-case.
I inserted exclude lines with correct case letters, and conversion worked as planned.
I have a file that should be added as binary but currently is not.
Is there a way I can force hg add the file as binary?
The file is an image that is corrupted (on purpose) for a test case.
Update: The problem in particular is that I have a patch file, so when I apply the patch it does not apply the same.
As per its documentation, Mercurial does nothing special for binary vs. text files. So you don't need to do anything special either, other than refraining from running diffs on them.
As John says Mercurial doesn't differentiate between binary and text files internally. It does display them differently in diff/patch output, and it provides binary-usable diffs for files the output filter thinks might be binary if you use the --git option (for git-style diffs). When decided whether or not to show a file as binary (show, not store) it bases the decision on whether or not there's a NUL (0x00) byte in the file. Try to get one in there if it really matters. Alternately consider sending a bundle (hg bundle) rather than a diff.
I recently converted a CVS repository to Mercurial. From the looks of it, everything went perfect. Except that every end-of-line character is in Unix style and I want them in Windows style.
I know the hg convert command can be used to "convert" a Mercurial repository to a Mercurial repository. Can I use it to do nothing on the repos but fix the line endings?
How they're stored in the repo isn't terribly important since you do your actual work with the checked out working directory, whose line endings you can control at update time using either of these extensions:
Win32TextExtension
hg-eol extension
more detail is available here: https://www.mercurial-scm.org/wiki/EOLTranslationPlan
I don't think there's an easy way to get hg convert to do what you want (short of writing code that plugs into convert's code. Unfortunately, convert's hg-to-hg conversions are also not entirely clean, due to the generalized model convert has. This may not be a problem if you're coming from CVS, though.
One way is to use whatever tool that normalizes line endings and run it on every file in a checked out copy then commit every file. But that should be considered a last resort solution since it will make the history "dirty" (files will appear to have been changed when they practically have not been).
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why does Mercurial think my SQL files are binary?
I've recently started using Mercurial and when I reverted one of my .SQL files, Mercurial performed a binary comparison. This obviously limits the visibility of the changes that were made, as there is no diff.
Is there an option to set file types to do a string compare?
I'm using Tortioise Hg 0.8.1 with Mercurial 1.3.1.
Mercurial doesn't actually handle text and binaries at all differently with respect to actual storage. It does however try to guess "would visually showing this diff be meaningful" when asked to show a diff to a user with hg diff, hg log -p, or when viewing a changeset in the web interface. When it's trying to make the "should I show this as if it's text" decision the test applied is "Is there a NUL byte (0x00) within the first 1000 bytes of a file.
So your file isn't being treated any differently except in how it's displayed to user output, but if you can find a NUL byte in there you can probably get that to stop too.
Alternately, the extdiff extension can be used to take total control of how diffs are displayed.
I don't know about the graphical part of TortoiseHg, but if you use the command line, then the --text flag to hg diff should do the trick: it makes Mercurial treat all files as text.
You should try adding these lines to ~/.hgrc:
[diff]
git=1
The git diff format works for binary files.
I converted my CVS repository into SVN repository.
It worked great, but one problem had occured....
I converted using a dumpfile, and the command was:
cvs2svn –encoding=( ) –sort=(PATH TO sort.exe) --default-eol=native –dumpfile=PATH\name.svn_dump –svnadmin=(PATH TO SVN ADMIN) (PATH TO REP)
loading the dump file:
svnadmin load PATH (to repository location) < PATH\name.svn_dump
Now some binary files, which in CVS are marked with -kb, have been corrupted. If I open both versions of a file in WinMerge, there look the same when the "Ignore Carriage Return Differences" is checked.
What seems to be the problem?
Did I miss something during the conversion?
thanks,
Oded.
Since you used the --default-eol=native option, any binary files that were not marked as binary in CVS will be stored to Subversion in "native" EOL encoding and will typically have problems like you described when checked out of Subversion. So, are you really sure that the files in question were marked as binary in CVS?
Please also note that there is a more proprietary CVS-like program called CVSNT whose repository format is different in several details to that of CVS. For example, it stores file modes in a way that is incompatible with CVS. cvs2svn does not support converting CVSNT repositories. If your repository was ever touched by a CVSNT client, you might have difficulties with your conversion. In that case, follow the tips in the above link and also consider setting the files in question to binary explicitly, for example using cvs2svn's --auto-props option.