Mixed up directory name case

[Hertroys A.]

> On Tue, 2012-04-03 at 09:58 +0200, Hertroys A. wrote:
> > I must be doing something wrong then, as it's not working:
> >
> > C:\ibi\repair>hg debugsetparents 1084
> >
> > C:\ibi\repair>hg debugrebuildstate
> >
> > C:\ibi\repair>hg rm -A "portal/menu.fex"
> 
> Missed a key step right here.

Doh, you're right, I missed the checkin!

> Fix them all at once.

The document is a bit undetailed though.

To find the conflicts I had to compare the output of:
	hg status portal
	hg status Portal

I removed all the files from 'portal', I'll add them back in later. Their case was wrong, after all.

Then after "hg co tip" I ended up with a mostly empty repository with LOTS of files marked as missing (!).
I fixed that with:
	hg revert -a -n
And when that didn't throw any errors:
	hg revert -a

I think it might help others to add that information to the wiki-page.
 
> > It would be really helpful for cases like these if hg would start a
> > merge-tool displaying the differences between the conflicting files
> > (there aren't any in my case), allowing to merge selected differences
> > between them, reviewing the result of the merge and eventually letting
> > the user choose which version to keep (much like how FreeBSD's
> > mergemaster does things).
> 
> This is a different class of conflict from a merge conflict. Some
> projects can and do have files that have names that Windows chokes on or
> that cause collisions, so merging away those situations is the wrong
> thing to do. Instead, we should be preventing the situation from
> occurring in the first place when using only Windows clients (which I've
> hopefully managed to do in 2.1.2).

I was more or less expecting a reply like that.

I am not asking that hg automatically does this. I am asking for a tool that - when the user runs it - does the merging for them, making the user confirm each merge.

There are valid cases to want to do such a thing, for example if a project was developed on a case-sensitive file system and now the project needs to be made compatible with a case-insensitive file system (HFS+, for example). Another example is of course the case-conflict I ran into caused by a bug in hg - that can happen again in some later version.
Having a tool for people who don't understand the details of Hg very well would safe these people a lot of sweat and fear. Every tool takes time to get acquainted with, if things like these happen when people are still new to the tool they're going to mess up without help.

I am currently the hg "expert" here at the company. If I leave and my boss is running into a problem like this, I think he'd end up just copying the files out of the repository and stop using "that buggy open source stuff" because it takes them too long to figure out what's happening.

But perhaps a tool like I described is more something for the Tortoise guys...

 
alban.hertroys at apollovredestein.com
T: 

Apollo Vredestein B.V. - P.O. Box 27 - 7500 AA Enschede - The Netherlands - Chamber of Commerce number 34223268 - http://www.apollovredestein.com

The information contained in this e-mail is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. You are hereby notified that any disclosure, copying, distribution or action in relation to the contents of this information is strictly prohibited. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail. The confidentiality of this message is not warranted. Apollo Vredestein B.V. rules out any and every liability resulting from this or any other electronic transmission.
--------------------------------------------------------------------------