I have converted a CVS repository to Mercurial, but the carriage returns are converted from CRLF (Windows style) to LF (Unix style). However, I want CRLFs in the repository! I realise that you can combat this problem with Mercurial extensions win32text and eol. But I would really prefer to have the repository converted with CRLFs in the first place.
I would like to hear if anyone has succeeded in this endeavour!
Hrm, I've not heard people say it does that before, but I've never tried to put CRLF in a repo before either. I'd guess it's not the mercurial convert doing the line ending change so much as it's the cvs export tool that it chains off to. I
Try using cvs2svn or cvs2git as an intermediary step as recommended here: https://www.mercurial-scm.org/wiki/RepositoryConversion#CVS
Related
I'm trying to compare and merge MySQL WorkBench files in SourceTree, and in order to do so I created a small shell script that extracts the content of the .mwb file and strips some useless counters from the XML file inside it.
Then I added this line to .gitconfig in the project's root:
[diff "mwbdiff"]
textconv = mwb-diff
and this in the .gitattributes:
*.mwb diff=mwbdiff
Now, if I change something on a .mwb, then "git diff" on console shows the correct differences, and SourceTree does it, too:
The problem is that if I try to do the same on already committed versions, I get nothing:
Same result if I try to merge. I still get the right output if I try to run GIT from the console like this:
git diff develop feature/four -- test.mwb
but if I try to merge, then I get unsolved conflicts and I don't know how to proceed.
I also tried to move the .gitattributes and .gitconfig changes into the global variables, and it actually works in the console, but it didn't help SourceTree.
I suspect it has something to do with the binary preview in SourceTree (Mac version), if I could disable it...
What am I missing? How can I solve this problem?
I think that this is not supported.
So to avoid calling git diff when it will ultimately just produce no output, SourceTree pre-detects whether files are binary or text on the disk, identified by whether in a quick sample of the initial chunk of the file contains a couple of binary zero's in succession. I can only assume that the odt formats include this sequence, so SourceTree treats them as binary. On Mac we have a binary preview pane which displays before/after of supported binary files but we haven't ported that to Windows yet.
At the moment we don't support your case and may not add it in the near future, because it's a pretty rare thing to do and most people would just see a performance penalty when git diff fails and we then fall back on other techniques. We'll keep this logged for possible future support.
Source: JIRA - textconv diff not generated
So in other words, SourceTree specifically avoids calling git diff for files that SourceTree considers to be binary. That means that any textconvs don't get called at all.
The only way to work around this would be to trick SourceTree into thinking that your file isn't binary. Which is probably not feasible.
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.
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).
We are just beginning to learn and evaluate Mercurial, due to an increasing number of nightmare merges, and various other problems we've had with SVN lately.
A client wants us to pull down a live copy of their site, do some SEO work on it, and push it back to them. They have no source control at all. I figure this is a great project to work on with Mercurial. Instead of putting it into our SVN and exporting when we are done, we'll use Mercurial... But right away it seems I have some problem :)
They have a file called ---.config which seems to cause our Mercurial to barf. It just can't commit that file. I've created the repo and committed everything else, but I just can't get this one file committed.
We are running on Windows 2008 x64 with TortoiseHG 1.0.
I suppose I could ignore the file since it is unlikely we'll need to work with it, but still - I'd like to learn how to use Mercurial a bit better. Is there a way around this?
EDIT: here is the error message:
('commit', GetoptError('option ---.config not recognized', '-.config'))
This happens when I hit the "commit" button in TortoiseHG with that file selected.
Not sure about hg, but most command line tools treat anything after a -- as a non-option. This is helpful if you have a filename that starts with -- or a wildcard that picks up such a file; try prefixing your filename or wildcard with --, e.g., hg command -- *.config.
The problem is that TortoiseHg did not escape filenames correctly when calling hg. When a filename starts with --, one must take extra care when using it on command lines.
I have just sent a patch which will hopefully make it into TortoiseHg 1.0.1, which is scheduled to be released later today.
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.