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

Re: svn propedit cannot chdir

From: Branko Čibej <brane_at_xbc.nu>
Date: 2002-08-13 21:03:09 CEST

Philip Martin wrote:

>Branko ÄŒibej <brane@xbc.nu> writes:
>>>This behaviour is enforced by the path-split regression tests. Within
>>>the subversion code there are some places where "" works as the
>>>current directory, and there are some where it doesn't work.
>>"" should always work, and we shouldn't have to do
>>(platform-specific?) checks for that in our code, those should be in
>>APR. (All of which implies that our canonicalization should just strip
>>off any leading ".[/]", thereby changeing "." to "".)
>I asked earlier and was told "." was a canonical path.

Yeah, by me, probably. Confusing, aren't I? :-)

> Can "" be
>canonical as well? Can we have two canonical forms for the same

No, there's only one canonical form, and we have yet to decide which it
is, and fix APR accortingly. Notice that I said that "" _should_ work,
not that it does.

>If the subversion libraries are to work with both "" and "." then the
>path library needs attention
>1. svn_path_is_child("", "foo")
> This gives NULL but I think "foo" would be better.
>2. svn_path_get_longest_ancestor("", "foo")
> This gives NULL but I think "" (assumming "" is canonical!) would
> be better. I think we also need to look at (".", "foo") here.

Either these functions work only with canonical paths, in which case
only one form is valid, or they canonicalize their parameters, but then
the question is again how canonicalization should work.

Tell you what: since you seem to be in the middle of this code anyway,
why don't you just decide about this and implement it as necessary?

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 13 21:03:42 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.