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
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.
I use Mercurial for game development, and I'm trying to use the LargeFiles extension included in Mercurial 2.0 to keep track of large binary assets. Unfortunately there isn't a whole lot of documentation on the extension, so I'm not sure how people are expected to use it.
For example, is there any way to safely clean out the .hg/largefiles directory? If I'm on the tip revision, and expect to always have internet access, then I don't need the old versions of largefiles cluttering up the repository, since that's the whole point of using the LargeFiles extension.
Also, how do I have more fine-grained control over where the largefile store is? I can only assume that it's created somewhere on the computer that ran hg init, but I have no idea about the details.
Thanks!
I don't have any guidance on how to safely clean out the .hg/largefiles directory.
Largefiles Store
The largefiles store seems to be stored, by default, at the one of following locations:
Windows: C:\Users\Username\AppData\Local\largefiles
OSX: /Users/username/Library/Caches/largefiles
Linux: (This is my best guess)
/home/username/largefiles
or /home/username/.cache/largefiles
User Configured:
This, however, can be changed in the global settings file using the usercache setting as follows:
[largefiles]
usercache = c:\path\to\largefiles\cache\
Note: This is not documented yet. This makes me wonder if it is subject to change.
Sources:
Largefiles Extension Documentation
User cache paths - https://www.mercurial-scm.org/repo/hg/file/41453d55b481/hgext/largefiles/lfutil.py (lines 84-103)
Undocumented largefiles.usercache setting - https://bz.mercurial-scm.org/show_bug.cgi?id=3088
I'm just posting this for anyone else coming into the thread from a search.
There's currently an issue using the largefiles extension in the mercurial python module when hosted via IIS. See this post if you're encountering issues pushing large changesets (or large files) to IIS via TortoiseHg.
The problem ultimlately turns out to be a bug in SSL processing introduced in Python 2.7.3 (probably explaining why there are so many unresolve posts of people looking for problems with Mercurial). Rolling back to Python 2.7.2 let me get a little further ahead (blocked at 30Mb pushes instead of 15Mb), but to properly solve the problem I had to install the IISCrypto utility to completely disable transfers over SSLv2.
I am writing a set of django apps and would like to use Hg for version control. I would like each app to be independent of the others so in each app there may be a directory for static media that contains images that I would not want under version control. In other words, the binary files would not all be in one central location
I would like to find a way to clone the repository that would include copies of the image files. It also would be great if when I did a merge, if there were an image file in one repo and not another, that there would be some sort of warning.
Currently I use a python script to find images and other binary files that are in one repo, but not the other. But a lot of people must face this problem, so there must be a more robust and elegant solution.
One one other thing...for reasons I do not want to go into, usually one of my repos is on a windows machine, and the other is on Linux. So a crossplatform solution would be nice.
Since Mercurial 2.0 the extension largefiles is now included in the main distribution. That extension keeps and manages large files outside of the "normal" repository in a way that you get the benefit of DCVS but without the benefit of exponential size and processing time growth.
Other extension that work along similar lines are SnapExtension and BigFilesExtension. However, those two are not distributed with Mercurial (you have to get them manually).
Mercurial can track any kind of file, for binary files if something changes then the whole file gets replaced not just the changes.
On the getting a warning if one repo doesn't contain a file, that's kind of the point of a DVCS is that the repos are related but are autonomous. You could always check and see what files were added during a synch or merge operation.
The current Mercurial book (by Bryan O'Sullivan) says, that Mercurial stores diffs also for binary files. How efficient this is, obviously depends on the nature of changes to binary files.
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 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.