Dave Cridland <dave@cridland.net> writes:
> I almost hate to contribute to this discussion, given that I'm not
> entirely sure it's not a bike-shed. However, I'm just throwing ideas
> about. I will happily code the relevant support code up for this idea if
> there's the slightest interest. I don't think I'd have a clue which
> functions actually need canonical paths, though.
>
> What about defining, in code terms, a "Canonical Path" as a structure
> (or object, in those language bindings which support them):
>
> typedef struct {
> char * s;
> size_t l;
> } SVN_PATH_COMPONENT;
>
> typedef struct {
> SVN_PATH_COMPONENT * c;
> size_t l;
> } SVN_PATH_CANONICAL;
>
> const SVN_PATH_COMPONENT svn_path_cwd = { 0, 0 };
> const SVN_PATH_COMPONENT svn_path_repository_root = { 0, 1 };
>
> Gives you type safety, such that it's impossible to pass a non-canonical
> path into a function expecting a canonical one, and allows for
> canonicalization of local paths to be based on any path seperators and
> cwd semantics you want.
>
> You do, of course, have to build some extra functions for making a "DAV
> canonical path" - URL encode each component, and glue them with '/' -
> and a "Repository Canonical Path", but discussions seem to be hinting
> that these are (potentially) different anyway.
>
> Thoughts?
The problem with changing the representation of paths is that paths
are being passed around in a _lot_ of code, and this code would then
have to be changed (at least as far as declarations are concerned).
The point is probably moot now though, since my "UTF-8 hack" should
give us all the degrees of freedom we would like while still retaining
exactly the same representation of paths (UTF-8 encoded component
names separated by the octet 0x2f in a C-string).
// Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 29 20:21:55 2002