Mercurial changing file names to Upper Case and doesn't track them - mercurial

I've been having some problems with mercurial and kiln, maybe you can point me in the right direction. Sometimes when I commit the files they get renamed as Upper Case 'Assembly.NameSpace' will be changed to 'ASSEMBLY.NAMESPACE' and if I try to commit after making changes to them they appear as not being tracked (Side note I found out about the renamed files after I committed).
No matter what I do they just wont be tracked. I tried add using the console, using hg workbench and nothing seems to work. For it to work I need to forget the files, then commit, then add them again and then commit, which it really sucks for me.

Is it possible the files already exist in the repository with different case? "Case Folding" is a problem for any system that needs to work on both systems that are truly case sensitive and those that are only case retentive. Mercurial has done a lot of work to degrade as well as possible when a case folding problem arises and there's a lot of detail about it in the Mercurial wiki.
On what OS are you working?
When you do that initial add of the files are you using a wildcard or specifying them by name?
Do the files on disk actually change case when you add them? Mercurial only alters files in the working director (the stuff outside of .hg) on update, so it seem pretty much impossible that just doing hg add; hg commit would change the case of a file in the working directory.

Upgrading to latest version will fix the problem.

Related

Mercurial wrongfully shows new files (really already pushed)

I have a mercurial version control installation in my company. We have central repository and regularly pull changes from there.
Several files on my computer are marked as newer ones. But really they already exist there.
If I delete them physically, they became marked as removed. If I revert them, they become newer ones.
I already tried to reload this repository to newer place, but situation was repeated.
Can anyone help me?
It sounds a lot like you're pulling but not updating.
Pulling gets the changesets others have made, but they don't become active in your code directory until you update to them.
If I've misunderstood, could you post a sequence of commands, with the output you get, to demonstrate the problem?
If you miss icon overlays for some files, you can try TortoiseHG - Update Icons (or just cd forward and back some time, restart Overlay Icon Server...)
If you miss icon overlays for all files of some type, you may reach limit of overlays for your OS (bundle of different Tortoise* can give such effect)

mercurial ignores sites/all/modules in Drupal Multi-site

I'm not going to get into the discussion on how to set up mercurial for a Drupal multi-site installation, but I've run across something that's boggling my mind.
I have a drupal multi-site installation which I'm trying to set version control up on. What I've done is to hg init in the Drupal Root, with an .hgignore that ignores drupal_root/sites/. This is what Is in my .hgignore, and it seems to be working fine:
# Glob syntax
syntax: glob
# Everything in sites
sites/*
This is working just fine, as mercurial finds everything else besides the sites folder. Now, inside the sites folder, the structure looks like this:
sites/
sites/all
sites/default
sites/domain1.com
sites/domain2.com
My problem is that when I do hg status inside sites, mercurial will not find sites/all/modules. I've tried multiple permutations of .hgignore, as I'd like to ignore sites/domain1.com/files, but nothing seems to work. I even deleted the repo, and started over without any .hgignore at all. sites/all/libraries and sites/all/scripts both show up just fine.
Could the .hgignore in the parent directory have something to do with it?
UPDATE: I just completely removed the sub-repo (I know it's not actually a sub-repo, but I'm limited here) deleted the repo in drupal root, and started over treating the entire installation as a single repo. Same thing, mercurial just will not find root/sites/all/modules.
UPDATE: #Ry4an - The behavior in the drupal root directory is correct. I'm trying to emulate sub-repositories since I'm stuck using Hg 1.3, which doesn't really implement them. So, my directory structure looks like this:
drupal_root/
.hg/
modules/
includes/
themes/
sites/
.hg/
all/
default/
domain1.com/
domain2.com/
So, I do want the repository inside drupal_root to ignore everything under drupal_root/sites, but I have a second repository inside drupal_root/sites that should handle everything there. That's the repo that's not finding everything.
What you're seeing is the behavior I'd expect. This glob rule:
syntax: glob
# Everything in sites
sites/*
ignores everything in sites, which includes 'sites/all', so Mercurial won't be looking down inside 'all' at all, so it won't see 'sites/all/modules'.
If you provide a full list of files and their paths annotated with what files you want ignored and what files you don't want ignored I'm sure someone can help you come up with the right rules, but it's not entirely clear from your question.
If you task is "ignore all, except one dir"
If you can write (and test) regexps
you can consult with this question and accepted answer in order to adopt regexp to your conditions
Another (slightly more inaccurate) solution can be
leave current "ignore all" pattern
add all files in sites/all/modules into repo by hand (hgignore ignore only untracked objects)
don't forget all new files, added later into modules, add explicitly to Mercurial (they will be ignored by rule)
Well, I feel like an idiot. The problem was that there was already a repository inside drupal_root/sites/all/modules. I don't remember putting it there, but it seems that mercurial ignores any directory that already contains a .hg directory. Thanks for the help everyone.

mercurial temporarily ignore versioned files

My question is essentially the same as here but applies to mercurial. I have a set of files that are under version control, and one save operation changes quite a lot of files. Some of the resulting changes are important for revision control, and some of the changes are just junk. I can "partition" off the junk into separate files. These junk files need to be part of a basic checkout in order for it to work, but their contents (and changes over time) aren't that important for revision control. Right now I just tell all our developers not to commit these files, but we all forget and it creates a lot of extra baggage in the repository. I don't really like the svn solution proposed because there are quite a lot of files and I want a simple clone to just work without all this extra manual work, so I was wondering if mercurial has a better alternative. It's kind of like hg shelve but not quite, and kind of like ignore, but not quite. Is there some hg extension that allows for this? Can git do it?
Mercurial doesn't support this. The correct way to do it is to commit thefile.sample and then have your developers (or better you deploy script) do a copy from thefile.sample to thefile if thefile doesn't exist. That way anyone can update the example file, but there's no risk of them committing their local changes (say their personal database connect string).
Aha! So TortoiseHG's repository and global settings have an Auto Exclude List where you can define a list of files that will be unchecked by default when the status, commit, and shelve dialogs open. So they still show up, but the user has to check them in order to actually do a commit. The setting is stored in hgrc, but it's under the [tortoisehg] heading so it's not supported by mercurial per se. Nevertheless, it fits my needs.
One solution to this is to use nested tree support (submodule in git), where the "junk" would be put in a different repository (to avoid cluttering the main repo), while enabling checking out the whole thing out in a consistent manner (right version of both repos in sync).
https://www.mercurial-scm.org/wiki/Subrepository?action=show&redirect=subrepos
In git, submodules are one solution to this issue - but they are not that great UI-wise. What I do instead is to keep two completely independent repositories, and using the subtree merge strategy when I need to update the main repo with the junk repo: http://progit.org/book/ch6-7.html

CVS to Mercurial conversion: end of line problem

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).

mercurial fails with a file named ---.config - any way around this?

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.