[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Filesystem normalisation
From: |
Stephen Leake |
Subject: |
Re: [Monotone-devel] Filesystem normalisation |
Date: |
Sat, 29 Nov 2008 06:48:44 -0500 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) |
Peter Stirling <address@hidden> writes:
> I've written a small module (it's one 'public' function and some
> support functions to make it clearer as to what it's doing) that
> solves the 'mtn add apple Apple' on Mac OS X.
What exactly is the problem? Is Mac OS X file system case insensitive?
> The idea is to have a function
> void plaform_fs_normalisation_hook( std::string & const in,
> std::string & out )
> that can be called from
> args_to_paths() (cmd.hh:146 on nvm
> 93e7e626c6ee8db33a21eabcfab00d97f1bed8c2).
This is what paths::to_external is supposed to do, mostly. Does that
not work here?
On the other hand, args should already be in the fs format, so I don't
understand why you need to do anything.
"paths" in mtn are supposed to be in a filesystem-neutral internal
format; to_external converts them to the current filesystem format.
> If this code is eventually included in monotone, then it would be
> possible to identify 2 files in a manifest that will conflict on
> disk,
This is done now, although not in a very friendly way.
> and perhaps perform an automatic rename.
That would be conflict resolution for 'mtn update', which is a logical
step.
> Currently it is appears impossible to checkout a revision that has
> conflicting filenames.
yes, if they conflict according to the local filesystem.
> The update aborts when it notices that a file with the second
> filename already exists, leaving the workspace with a _MTN/ detached
How does your code solve that?
--
-- Stephe