The file is not capitalized in the directory.
There is nothing that would indicate that the file is different from any other file.
Yet, on commit, the file name is capitalized including the type "CS".
What's up with that?
It's not just filenames. It can also happen to any segment of the file's path.
This was a recent bug in Mercurial itself on Windows (discussion). It seems to be resolved in Mercurial 2.1, which will be included with TortoiseHg 2.3. There is a release candidate available, TortoiseHg 2.3-rc, and the final release should be out in less than a week.
Related
I'm trying to merge the latest revision of our main branch into a much older branch. There's only two files that have conflicts, but the conflicts are complicated and I'd like to manually copy the changes from the more recent revision and fix some things. There's been a tonne of commits since the last commit into the old branch and I don't know when those two files were changed.
Using TortoiseHg, how can I find the latest revision on any branch where a particular file was changed?
From Windows Explorer, right click on the file whose history you are interested in.
In the TortoiseHG menu, select "Revision History":
This will bring up a window showing only the changesets which have modified that file (in any branch). It should also show history across tracked file renames (if the hg log "follow" option is enabled in hgrc), copies, and moves.
You can also get to the same thing from within the THG Workbench application, from the lower files list, where it is called "File History":
Either will bring you to:
Furthermore, command line equivalents of this screen would be to use hg log file and hg annotate file.
I discovered some case folding problem by running hg manifest under windows. Here is a segment of the manifest output.
src/include/a.h
src/Include/b.h
but they all appear to be under src/Include in my local windows file explorer view. I just wonder will it cause any problem in the future.
Yes, that can cause problems - on windows systems or mac systems where case-sensitivity is switched-off. Should you ever have a file with identical names inside those directories, then - provided my memory serves me well - mercurial on a system with case-insensitive file systems won't be able to checkout revisions where that seemingly "duplicate" file exists and mercurial will throw an error.
My advice: use directory and filenames such that there are no duplicates in paths when transferred to a case-insensitive file system, and also filenames unique enough so that it won't cause problems either.
Related question: https://softwareengineering.stackexchange.com/questions/275310/why-isnt-the-addremove-recommended-by-default-in-mercurial
I am working on a LaTeX project and was new to Hg when I started on it about a week ago. Basically I tracked all the files in the folder using the command hg addremove *. After realizing my error, I have been tracking only the files which I think I will repeatedly edit. However, I haven't yet untracked all the files I asked Hg to track at the start of the repo.
The result is that Hg not only tracks the source files with .tex extensions but is also tracking the resulting .pdf files — something that I think is resulting in an unnecessary bloat in my repo. How can I start fresh?
On a related but separate note: is it a bad idea to track MS Word files (say ending in .docx) using Hg? My method of using LaTeX is somewhat like this: https://tex.stackexchange.com/questions/61967/how-to-run-latex-from-word
If add a string Rome was not built in a day. to a text file and save it, the new version of the text file is just 28 characters larger than the old version. I am not sure if .docx works in a similar way. Hence the question.
Regarding your first question
hg convert is what you're looking for -- ConvertExtension.
You want to use the --filemap option to exclude all your PDF files.
Because the filemap doesn't support wildcards/globs (*.pdf), you'll need to build a list of all the PDF files in your repository in order to exclude them. If you're on a unix like platform you can do that with find.
I just start using Mercurial yesterday (I don't have much programming experiences). I noticed, if I rename a 200MB file, ideally the repository size should not change, but I found it increased 200MB.
Is this a bug/weakness of Mercurial? Any chance it could be fixed/improved in future?
Update:
I have just tried TortoiseGit 64bit version on Windows 7 64bit. It didn't create duplicate contents when renaming files. But it seems once I renamed a file, its history was lost.
Update 2:
See tonfa's comment below. From Mercurial wiki - GSoC Ideas 2010:
Project Ideas
Lightweight copies/renames
(very difficult - a successful student
will become an expert in Mercurial's
storage format and transmission
protocol)
Copies and renames currently are not
too efficient. Mercurial copies the
copied/renamed source file to the new
initial revision of the target file in
its internal history store. For
renames, this is especially
counter-intuitive, as renaming a large
file grows the store by the file's
size. It would be better if Mercurial
had some way of referring to the
existing revision from the new file,
while preserving backwards
compatbility and bounded I/O
guarantees for retrieving revisions.
See issue883 for discussion.
There's an mq from an old attempt at
this located here.
Contact: mpm, tonfa, cyanite
No, it is not a bug. Renaming in mercurial causes removing file in old place and creating it in new one (with keeping the reference though, for merge and logging purposes).
So at least for now you can do nothing.
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.