A user said:

"Let's assuming you have example.txt tracked in a mercurial repository...

Rename the file to Example.txt (let's assume you are working with a case-sensitive FS on the receiving end that clones down the repo and happen to require Example.txt). The include will fail due to missing file/folder errors. The workaround to this is to do two separate commits:

1. Move the renamed file to somewhere else. Commit.
2. Move the file back (the upper-cased letter name) back to its original location. Commit.
3. New file name (Example.txt, NOT example.txt) is detected and in repository as it should have been all along.

The workaround is fine; however, it is an unexpected inconvenience. I would expect when I make a change to the filename (including capitilization of any letter in its name) that the change would be detected and the repository updated with that change – even on a non-case sensitive FS like win8's.

So, to clarify... sourcetree is just not detecting the change file name. the third party system is just an example of how a linux machine would consume the repository.

If you were to ls in the directory the example.txt would be, it'll read, "example.txt" – indicative that sourcetree did in fact not detect the changed file name – and therefore assumed that nothing new was there to commit, nor was it able to be seen on the third party system (how I originally discovered this issue)."

---------

I've personally reproduced this; though Mercurial on Windows itself treats "Example.txt" or "example.txt" as the same file without any changes done. But if that particular change is done on Linux itself, Mercurial on Linux will treat it as different files. Hence, this might be a Mercurial on Windows problem rather than SourceTree.

This is a request for improvement on SourceTree's side instead - to help SourceTree on Windows to recognize case sensitivity.