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.
Related
I am using CVS2SVN tool(v2.5.0) running with python2.7 to convert cvs repository to svn. All initial validations are passed but get an error saying same file cannot contain in the actual path and Attic directory.
ERROR: A CVS repository cannot contain both c:\mycvs\programs\path\files\MyTest.java,v and c:\mycvs\programs\path\files\Attic\MyTest.java,v
How do I solve this error?
Thank you
I am able to correct the issue after reading more documentation and understands what is Attic and when it gets created. CVS creates the directory Attic and keeps the files which have two conflicting histories and even CVS does not know the correct history of those files.
Both solutions recommended by cvs2svn have pros and cons. You can use --retain-conflicting-attic-files to convert files in both places or remove Attic versions. I chose the second one and restarted the conversion.
Read here for more details
http://www.mcs.anl.gov/~jacob/cvs2svn/faq.html
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.
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).
I'm using cvs2svn to migrate from CVS to SVN.
I've noticed a problem with my binary file after the conversion was completed.
I'm using auto-props file, which is very helpful.
After the conversion I took the file from CVS and compared it to the same file from SVN.
The file is binary. Using WinMerge, I see that there is a difference between the files.
What can be the problem?
Are you using cvsnt? If you do, cvs2svn doesn't understand that your file is binary, because cvs and cvsnt flag binary files differently. It is simple enough to write a program that converts this. I had to do that.
Now, if you have a binary file that isn't marked as binary in cvs, or it is marked using the cvsnt syntax, and the file contains patterns like "$Id" or "$Date", then Subversion will substitute those patterns when you check out the files. Usually that means your binary file will get corrupted.
How to convert: If the file contains "kopt b;" assume it is binary, although technically a file may be binary in some revisions and not in others. For all binary files, insert "expand #b#;" before "symbols" near the top of the file, so the header looks something like this:
head 1.1;
access;
expand #b#;
symbols
When you do this, be careful not to change anything in the rest of the file, e.g. line endings.