monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] bug in monotone


From: Helmut Stiegler
Subject: Re: [Monotone-devel] bug in monotone
Date: Fri, 09 Jan 2009 10:54:46 +0100
User-agent: Thunderbird 2.0.0.18 (Windows/20081105)

Hi Thomas and Markus!

Thank you for your fast reply!

But the documentation states (section internationalization):

File path names in the workspace are converted to the locale's character set (determined via the LANG or CHARSET environment variables) before monotone interacts with the file system. If you are accustomed to being able to use file names in your locale's character set, this should "just work" with monotone.

i tried to set these variables (windows version), but it did not help.

BTW for native Windows using the wide-char functions and WideCharToMultiByte should be quite straightforward to get utf-8 filenames...

But I also tried the cygwin build of monotone in the hope, that it is handled properly there. However this one ends up with this error:

mtn: error: sqlite error: unable to open database file
mtn: error: make sure database and containing directory are writeable
mtn: error: and you have not run out of disk space

A TODO Item in the documentation however is the handling of case folding conflicts. Alas i was not yet able to figure out, how it works now. As i want to convert a couple of big repositories to a distributed vcs, i tried mercury too, but merury doesn't deal well with case folding conflicts. My suggestion for this item would be to internally create a rename when comitting, if done in a case folding filesystem. Of course checkouts with case folding conflicts of versions committed in a case sensitive filesystem into a case folding filesystem will never work. A warning when comitting even on case sensitive filesystems would be nice hence. But imho it should be a goal, at least to be able to retrieve any comitted changeset in the same filesystem, where it was comitted (this is not the case with mercury).

Regards
Helmut



Markus Wanner schrieb:
Hi,

Thomas Keller wrote:
  
Anyways, the error is quite common and unfortunately won't be fixed any
time soon.
    

Let's at least say: we should try to improve the error message. Do we
have some sort of TODO file or something? Or is this a summit'09 task:
to organize todo items?

Regards

Markus Wanner



  

reply via email to

[Prev in Thread] Current Thread [Next in Thread]