monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Filesystem normalisation


From: Derek Scherger
Subject: Re: [Monotone-devel] Filesystem normalisation
Date: Sun, 30 Nov 2008 21:18:24 -0700

On Sun, Nov 30, 2008 at 6:14 PM, Peter Stirling <address@hidden> wrote:

a start toward windows too. To that end, can someone point me as to
where I should change the build configuration scripts to add
this file, and the required linker argument? I need that so that I

Monotone uses the autoconf/automake build system. The primary input file you'll need to make changes in is Makefile.am.

can check whether it works (ie hook in the right place), and
hopefully write some tests to show that it works.

I don't think args_to_paths is the right place to make this change though. That function only deals with paths on the command line and you may just as well get a bad path from a revision committed by someone else on a system that is case sensitive or doesn't have whatever filesystem restrictions that your system does.

It's a long standing bug that we've known about for a long time. OSX uses different charsets for output to the user verses paths to the filesystem and no one has ever taken the time to straighten things out. The right solution is probably somewhat complicated though. I think various people (myself included) would probably prefer to see a few different path types (internal - encoded in utf8; user - encoded in their charset;  and filesystem - encoded in the appropriate charset for the platform you're running on whether that's the user's charset or the filesystem's charset).

I personally find the path handling code we have at the moment a bit complicated though and improving that might also help. I'm not entirely sure what the right approach is here though. One thought I had was to make the workspace class contain a bit more state, and remove some statics and then perhaps do translation between paths relative to the current directory and paths relative to some specific workspace object rather than the initialization startup magic that is currently used. We would probably still want to chdir to the "current" workspace as well.

Hope this helps.

Cheers,
Derek




reply via email to

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