kfogel@collab.net wrote:
>>Example:
>>
>>/wc/File1.txt
>>
>>Edit this file with an editor. Then save the modifications. Now, some
>>editors on Windows change the case of the filename. Either to all
>>lowercase or all uppercase. Especially some older editors change the
>>case to all uppercase. That means we get
>>
>>/wc/FILE1.TXT
>>
>>now, if we do an 'svn up', the file will get reverted to
>>/wc/File1.txt
>>and all local modifications are gone.
>
>
> That's weird. Why doesn't 'svn up' notice that the file (since it's
> the "same" file) is locally modified, and merge the repos changes if
> any? (If there are no repos changes, nothing should happen, right?)
It happens even if there are no repo changes. The 'svn up' will find
that the file does not exist (I guess it does compare the filenames case
sensitive) and just reverts the file from the BASE. That's why the local
modifications get lost: the reverted file from the BASE overwrites the
modified file.
> I don't have easy access to a case-insensitive system. Can you debug
> into the update editor, perhaps? I'm very puzzled by the behavior.
I'm not very familliar with the update editor. All I can say is that by
looking through the code subversion does compare filenames/paths case
sensitive and that way misses most of the time that a file "is there" or
that it will overwrites a file - it just thinks that the file doesn't exist.
The problem is that the function to check if a file exists is
case-insensitive (apr uses the windows API PathFileExists()), but the
string comparisons subversion uses are not.
> By the way, regarding your comment in the issue about setting the
> repository case-insensitive: this protection could be completely
> implemented in a hook script. I don't think anyone's posted such a
> script, but it wouldn't be that hard to write (I've seen them for CVS,
> for example).
Good idea. I will have a look at that some time.
Stefan
--
Build a man a fire - keep him warm for a day, set a man on fire - keep
him warm for the rest of his life.
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 8 00:56:04 2004