Backwards compatibility (was Re: how can you tell you have merged?)

[Bill Barry]

Matt Mackall wrote:
> On Thu, 2008-09-11 at 16:32 -0600, Bill Barry wrote:
>   
>> Matt Mackall wrote:
>>     
>>> I frankly can't see us ever finding a reason to change this sort of
>>> stuff, short of making a Mercurial-NG that vastly improves the
>>> underlying design. That will not be Mercurial 2.0, it'll have a new
>>> name. Because it will almost certainly require converting repositories.
>>> Even still, I suspect the command line interface will be nearly
>>> identical to aid in porting tools.
>>>
>>>   
>>>       
>> Just because we don't see it, doesn't mean it isn't possible.
>>
>> Btw... (sorta completely off topic): has anybody thought about 
>> implementing version control as a file system (getting rid of the 
>> current filesystem layers, some of them with their case insensitivity 
>> problems). I was thinking about this the other day. As I see it there is 
>> only two ways to get rid of all of the problems of case insensitivity on 
>> windows:
>> 1. require the user to use a case sensitive file system on windows (the 
>> only ones I know of are ext2/ext3; I was going to try hg on one to make 
>> sure it all works)
>> 2. make it so that you can mount the repository as if it was a separate 
>> partition (or even make it actually a separate partition, I don't know 
>> if that would be any more or less simple) pretending to be its own 
>> filesystem
>>     
>
> All quite doable. In fact, with FUSE you can do it in userspace, in
> Python. But I'm not sure what the advantage is: most of the interesting
> SCM commands (commit, diff, status, log) don't have natural filesystem
> analogs. The ones that do (mv, cp) are fairly infrequent.
>   
I was considering the possibilities for bypassing case sensitivity 
problems in windows. I've had the following problem happen multiple times:
person 1: commits "file1.txt"
person 2: commits "File1.txt"

With both people on windows, this is a relatively hard problem to fix. 
The choices I can think of are:
1. With the mq extension's strip command the person who would not have 
made their revision public yet removes it and reimplements the change
2. Both people have their changes published into a repository on a case 
sensitive filesystem where their change can be fixed.

This problem gets bigger if you have these files in one case and then 
update to a revision with it in another case.

Btw, in windows it could work much like a truecrypt filesystem (I think 
they are essentially user mode). It doesn't actually have to be a 
separate partition (what clearcase needed I thought).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20080911/c8e24074/attachment.htm