[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] Canonical Paths

From: Marcus Comstedt <marcus_at_mc.pp.se>
Date: 2002-08-29 00:44:40 CEST

Philip Martin <philip@codematters.co.uk> writes:

> Evidence of a potential user, but one who appears to have not yet
> tried to compile APR, let alone Subversion. What about neon, or db4,
> you will need at least one of those, do they work? Looks like a
> hypothetical problem so far :-)

It's not a problem right now, I'll grant you that. But now is the
time when we can prevent it from becoming a problem later, right? Can
we gratitiously change the canonical format later without messing up
existing repositories and/or WCs?

> I'm not trying to make life hard for you, I'm making it better. The
> current path library's use of ".", which is distributed over the file,
> will be factored into two macros and so be easier to change. You may
> want to look at svn_cl__push_implicit_dot_target as well...
> However, as I said in an earlier mail, we cannot use "" at present.
> If someone wants to fix APR, or wrap all Subversion's APR calls, they
> can do it. My priority is the systems I use, which happen to run
> Subversion *now*.

I don't really see why we can't use "" now. When we get paths from
the user, we replace the real directory separator with "/" (which
incidentally might pose a problem on MacOS Classic, if you have files
with "/" in the name), convert the path components to UTF-8, and
replace the real name of the current directory with "". Upon feeding
the paths to system calls, we do the reverse transformation.
Currently only the UTF-8 transformations are actually carried out, but
all these steps are reversible AFAICT. What am I missing here?

  // 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 00:45:38 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.