[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Filesystem normalisation
From: |
Peter Stirling |
Subject: |
[Monotone-devel] Filesystem normalisation |
Date: |
Sat, 29 Nov 2008 05:44:56 +0000 |
Hi,
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. It uses
Mac OS system calls to do its work so it will will need to only be
compiled and linked
for that.
I've not worked with autoconf etc so I don't know how to do that
conditional
compilation (I've made a small driver program to work on it). Since I
don't know how
to do that I've not been able to build monotone with it, and
consequently can't make
a monotone style unit-test, or a patch that can be applied.
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).
After the hook is complete the 'out' parameter contains either a
version of the filename
as the filesystem stores it on disk, or it will be the same as
'in' (if an error occurs)
I chose to punt because I don't know if it would be bad to call one of
die macros in
that context.
filepath constructors in paths.cc could probably also call the hook
(args_to_paths()
eventually calls them), but they are also called by other bits of
code, and as I can't
run the test suite I can't tell if that would break anything.
Currently there is an ifdef'd function for non-mac builds, and for
linux it would
probably continue to be a no-op, but I think code with the same
purpose as mine could
be written for windows (I could take a bash at it, but I've never done
windows
programming so someone more familiar might be better).
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, and perhaps
perform
an automatic rename. Currently it is appears impossible to checkout a
revision that
has conflicting filenames. The update aborts when it notices that a
file with the
second filename already exists, leaving the workspace with a _MTN/
detached
The extra linker arguments are '-framework CoreServices'
test_paths.zip
Description: Zip archive
- [Monotone-devel] Filesystem normalisation,
Peter Stirling <=