Re: [Monotone-devel] "" is invalid file_path?

[Nathaniel Smith]

[not sure you sent that to the list]

On Mon, Sep 8, 2008 at 6:04 AM, Stephen Leake
<address@hidden> wrote:
> Ok. Suppose I have a workspace /home/user/stephe/work.
>
> My current directory is /home/user/stephe/work.
>
> The external path "" refers to the root of the workspace. Sometimes
> (rarely) I have to be able to name that.

Usually you refer to that as ".", though that's only one of many
external paths that refers to the directory ("foo/.." works too, for
example), and it depends on what directory you're in.

>> _external vs. _internal basically denote different syntaxes for
>> writing paths as strings -- _external is the stuff that people type on
>> the command line.  "" is a valid path in _internal-ese, but not in
>> _external-ese.
>
> Why not?

Well... because we did it that way :-).  And because it's something
specific to mtn to learn, that is pretty obscure.  In principle one
could declare that mtn treats "" like "." (when in the root directory,
I'm not sure *what* should happen when you're in a subdirectory).  I
guess I don't have a strong opinion either way.

>> Why do you want to use the _external-handling functions for parsing
>> path strings generated programatically by mtn?
>
> Because those paths are intended to be used (and in some cases
> generated) by user tools; I thought that was the intent of
> file_path.as_external().

I guess it depends -- external mostly means "UI" and internal means
"data structures", ATM; neither of those is exactly the same as "used
programmatically by mtn and user tools and the user directly in a text
editor".

> Since the intent of the conflicts file is to let external tools edit
> it to provide resolutions, those strings "come from the user". We can
> easily add a restriction that "relative paths must be relative to
> workspace root" in the definition of the 'automate show_conflicts'
> basic_io format.

I would tend to think that show_conflicts, like the rest of basic_io,
should provide the easy-to-parse standard-rules-using internal-style
paths.

> But there is another difference; external paths use OS syntax for
> directory separators; internal paths use '/'. So if an external tool
> wants to use paths from the output of 'automate show_conflicts', the
> paths should use they system directory separator; they should be
> external.
>
> On the other hand, this only matters on Windows, and every Windows
> tool I know of now tolerates '/' as a directory separator. So using
> internal paths in automate show_conflicts is ok in practice.
>
> Until we port mtn to VMS :).
>
> And that may just be my experience; there may be other Windows tools
> that insist on '\'. I haven't checked the Microsoft documentation on
> the core OS functions.

Windows (and DOS) have always accepted / as a path separator in their
system API.

> More importantly, there is also a character set difference;
> file_path.as_external() calls charset.cc utf8_to_system_strict(),
> which converts to the system charset. I can't find the definition of
> utf8 right now (where is that class defined?); I assume its
> constructor does the system_to_utf8 conversion.

Actually it's assumed that strings passed into the _external
constructor are given in utf8 (this is a hole in our usage of the type
system).  They usually come from command line arguments, which we
convert to utf8 in the command line processing code.

Note that "as_external" is basically "as a string that's sensible to
display to the user in the UI" right now, though -- the name is a lie,
it's not the inverse of from_external.  There isn't any guarantee that
going external -> file_path -> external will roundtrip, and similarly
for file_path -> external -> external.

> I believe we should assume external tools expect file paths in the
> system character set; they should be external.

That seems logical.

> So I'm left with a problem; if I use external paths, and a user
> invokes 'automate show_conflicts' when the user current directory is
> _not_ the workspace root, all the file paths will be wrong. Or at
> least, the user tool will have to be invoked from the same working
> directory; that's not good, since the intent of the conflicts file is
> that it be used asynchronously; paths should be relative to the
> workspace root.
>
> I could add a restriction that 'automate show_conflicts' (and any
> similar commands) must be invoked from the workspace root, but that
> seems like a kludge.

Ew.

> On the other hand, if I use internal paths, and the user is on a
> system where the system character set is not utf8, all the file paths
> will be wrong. Unless external tools are prepared to translate from
> utf8 to system.

That might be the best solution.  I haven't followed exactly how this
conflicts-handling workflow is intended to work, though, so dunno.

-- Nathaniel