Re: [Monotone-devel] bug in monotone

[Thomas Keller]

Helmut Stiegler schrieb:
> 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.

Yes, because it used to work on *nix, but it does not on Windows nor
does it on Mac OS X. A pal of mine did an excessive write-up on this
topic some time ago, its available here:

        http://monotone.ca/wiki/FileSystemIssues/

Its based on monotone-0.32, but the problems haven't changed since then,
obviously they seem to be largely identified. Its just that no one got
around and implemented it so far.

> 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
>     /

This more looks like an access problem. AFAIR, monotone must be able to
create the database' journal file in the same directory where the
database resides in.

> 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).

Some possible solutions are noted for this case in the wiki as well:

        http://monotone.ca/wiki/CaseInsensitiveFilesystems/

though they largely favor a workspace-merge solution, i.e. transport the
conflict to the client which has the case-insensitive filesystem and
prompt him to rename / drop something. This would still make problems
for checkouts or updates which contain different files with identical
lowercase names.

In the end in most cases such conflicting filenames are not wanted by
the user, so what we should actually do here IMHO is to warn or even
hinder the user to add a file with an identical lowercase name.

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature