You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Shlomi Fish <sh...@iglu.org.il> on 2004/06/20 14:07:53 UTC
Issue #1901 (double slashes screw things): Patch, and some strategy questions
Hi all!
Attached is a proposed patch to Issue #1901:
http://subversion.tigris.org/issues/show_bug.cgi?id=1901
The issue concerns the fact that copying two URLs with double slashes in
certain places, can cause Subversion to crash with an assertion (and possibly
other problems as reported in the comments). The patch fixes them by ensuring
that double slashes are removed at the beginning of the call to
svn_client_copy() and friends.
A possible problem is that: (which I wrote in the Issue Page):
<<<
Well, the patch I sent above corrects the problem, but I'm not sure if in the
right way. It does so, by filtering out double slashes from URLs inputted to
the svn_client_copy() and svn_client_move() functions. So, the bug still
exists in the lower levels, but it isn't encountered this way.
We should decide whether we can deal with double slashes in URLs (or in paths)
when being inputted at every stage, or that the routines can be expected to
fail if given such input.
>>>
What do you think?
Here's the log:
<<<
Fixes Issue #1901 ( Crash in copy command with URL with double slashes ).
* include/svn_path.h
Added the declaration of svn_path_url_remove_multiple_slashes().
* libsvn_subr/path.c
Added the definition of svn_path_url_remove_multiple_slashes().
* libsvn_client/copy.c
(setup_copy): Filtered out multiple slashes in the URLs in the calls to
svn_client_copy() and friends.
* tests/libsvn_subr/path-test.c
Added tests to test the svn_path_url_remove_multiple_slashes() function.
* tests/clients/cmdline/copy_tests.py
Added a regression test.
>>>
Regards,
Shlomi Fish
--
---------------------------------------------------------------------
Shlomi Fish shlomif@iglu.org.il
Homepage: http://shlomif.il.eu.org/
Quidquid latine dictum sit, altum viditur.
[Whatever is said in Latin sounds profound.]
Re: Issue #1901 (double slashes screw things): Patch, and some strategy questions
Posted by Ben Reser <be...@reser.org>.
On Sat, Jul 03, 2004 at 07:28:08AM -0400, Josh Pieper wrote:
> Yes, this is a symptom of a larger problem, namely that
> svn_path_canonicalize doesn't return a canonicalized path. Canonical
> would mean that any two input paths that referenced the same file
> should have the same output path (at least relative to the same root).
> svn_path_canonicalize should really behave more like
> svn_path_get_absolute, except without the requirement that the file or
> path actually exist on disk. I'm working on it now.
Yeah because it can't. Not without more information than it could
possibly ever have.
We know the rules tha our protions of the URLS follow. But we don't
know anything above the root of the repos. Unfortunately there is no
way of knowing where that lies.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue #1901 (double slashes screw things): Patch, and some
strategy questions
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sat, 3 Jul 2004, Josh Pieper wrote:
> Klaus Rennecke wrote:
> > Ben Reser wrote:
> >
> > >[...]
> > >
> > >We need to accept double slashes. See Issue #1779 and my comments on it
> > >in:
> > ><20...@occipital.brain.org>
> > >http://www.contactor.se/~dast/svn/archive-2004-03/0558.shtml
> > >
> > >The correct fix is to fix whatever is segfault when it encouters
> > >multiple slashes...
> > >
> >
> > As stated in an earlier followup
> > http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=69409 I am
> > pretty convinced that this issue is actually part of a more general
> > problem. There should be an algorithm floting around on my desktop
> > somewhere, but I don't have the time to port it from Java and check
> > legal at the moment.
> >
> > Sorry if I'm repeating myself, but I think this may turn ugly if you fix
> > the issue in small increments every time someone finds a new angle to
> > this. See <http://rfc.net/rfc2396.html#s5.2.>
>
> Yes, this is a symptom of a larger problem, namely that
> svn_path_canonicalize doesn't return a canonicalized path. Canonical
> would mean that any two input paths that referenced the same file
> should have the same output path (at least relative to the same root).
> svn_path_canonicalize should really behave more like
> svn_path_get_absolute, except without the requirement that the file or
> path actually exist on disk. I'm working on it now.
>
Good. You might also want to clarify the documentation for
svn_path_canonicalize stating whether it works also for URL:s or not. For
URLs, please be careful to just touch the path component...
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue #1901 (double slashes screw things): Patch, and some strategy
questions
Posted by Klaus Rennecke <kr...@tigris.org>.
Ben Reser wrote:
> [...]
>
>The above is taken from:
>http://www.faqs.org/rfcs/rfc2396.html
>
>Note that a segment can consist of no characters.
>
>Incidentally, no special meaning is given to /./ and /../ but everyone
>seems to apply them.
>[...]
>
Keep reading RFC 2396 up to Section 5.2, Steps 6c-g, they are pretty
detailed about normalising the relative references in URLs.
Granted, Step 5 states that if path starts with / it is absolute and 6
should be skipped. But it seems that the majority of applications apply
the normalisation no matter what. Even when they don't have to resolve a
URL relative to a base.
Section 6 states that normalisation is scheme specific. If it serves
consistency to declare this normalisation mandatory for absolute svn
URLs as well, then why not just do it? I'm not aware of any more
specific normalisation rules for http and https, but I can't see any
harm in doing it there too.
/Klaus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue #1901 (double slashes screw things): Patch, and some strategy questions
Posted by Ben Reser <be...@reser.org>.
On Sun, Jul 04, 2004 at 03:25:31AM +0200, Branko ??ibej wrote:
> I don't think that's the case. I believe hierarchical URL schemas (all
> of ours, http[s]://, svn[+...]:// and file:// are such) pretty much
> define how the path part should look like.
Correct but what it means is up to the app. That's what I meant.
> And the path portion of the
> file:// (not file:///!) URLs is _not_ interpreted by the OS. It's
> converted _to_ an OS-specific path -- it's merely a coincidence that
> everything after the second slash happens to look like a canonical path
> on Unix (well... not really a coincidence, but let's not split hairs).
Well that's not entirely true. file:/// are more tied to the platform
that a URL is. Ultimately we do some translation of the URL into a
path for that system, but the vast majority of it get passed through.
> As far as I know, double slashes aren't allowed in the path part of URLs.
That's not what the URL BNC says:
hier_part = ( net_path | abs_path ) [ "?" query ]
net_path = "//" authority [ abs_path ]
abs_path = "/" path_segments
path_segments = segment *( "/" segment )
segment = *pchar *( ";" param )
param = *pchar
pchar = unreserved | escaped |
":" | "@" | "&" | "=" | "+" | "$" | ","
The above is taken from:
http://www.faqs.org/rfcs/rfc2396.html
Note that a segment can consist of no characters.
Incidentally, no special meaning is given to /./ and /../ but everyone
seems to apply them.
> I think it's pretty much obvious that all our APIs, except the two you
> mention, require a canonical path (or URL) encoded in UTF-8. I'd
> actually go as far as to require the coding to be in Normalized Form C,
> for consistency -- not that we can guarantee that even in our own client
> programs right now.
Well it's not documented anywhere. It seems that this is our intention,
but without documentation I don't think we should be surprised when
clients, including our own, aren't following this.
> "Principle of least surprise" here. Ah, except svn_path_local_style. :-)
Ahh yes...
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue #1901 (double slashes screw things): Patch, and some strategy
questions
Posted by Branko Čibej <br...@xbc.nu>.
Ben Reser wrote:
>On Sat, Jul 03, 2004 at 07:28:08AM -0400, Josh Pieper wrote:
>
>
>>Yes, this is a symptom of a larger problem, namely that
>>svn_path_canonicalize doesn't return a canonicalized path. Canonical
>>would mean that any two input paths that referenced the same file
>>should have the same output path (at least relative to the same root).
>>svn_path_canonicalize should really behave more like
>>svn_path_get_absolute, except without the requirement that the file or
>>path actually exist on disk. I'm working on it now.
>>
>>It seems that in addition to this problem, there may also be
>>sub-commands that don't canonicalize their paths/URLs before using
>>them. I'll see what can be done about that too afterwards.
>>
>>
>
>Before we can really fix this we need to answer the following questions:
>
>a) What constitutes a "canonical" path?
>
>b) At what level does the API require a "canonical" path?
>
>c) At what level is the API required to produce a "canonical" path?
>
>Without these answers, we can't really fix this.
>
>Here are my answers:
>
>a) Right now we're using the following definition:
> Is not ".", Does not end in "/".
>
> If we're going to use the same rules for canonicalizing URLs we need
> keep a few things in mind. It is up to the server, how to interpret
> the path portion of the URL. In our case we have two servers that
> we have to mainly worry about and then file:/// which is interprted
> by the OS.
>
>
I don't think that's the case. I believe hierarchical URL schemas (all
of ours, http[s]://, svn[+...]:// and file:// are such) pretty much
define how the path part should look like. And the path portion of the
file:// (not file:///!) URLs is _not_ interpreted by the OS. It's
converted _to_ an OS-specific path -- it's merely a coincidence that
everything after the second slash happens to look like a canonical path
on Unix (well... not really a coincidence, but let's not split hairs).
> We know that generally all of them interpret the following things in
> special ways:
> //
> /./
> /../
>
> We also know that // may in some cases, though probably rare a
> different path in one of our servers (Apache).
>
>
As far as I know, double slashes aren't allowed in the path part of URLs.
> However, trying to permit // looks like it's going to end up being a
> real hassle. Using a path with // would already be problematic, and
> we haven't seen any users complaining because their paths with // in
> them don't work. (By this I mean a path where
> http://www.example.com/whatever//foo differs from
> http://www.example.com/whatever/foo in what the server returns, not
> people using // on accident as the issues we're talking with deal
> with.
>
> As a result I'm inclined to think (despite my previous objections)
> that a canonical path does not contain the following things:
> Is not equal to "."
> Does not end in "/"
> Does not contain "//", "/./" or "/../".
>
>
I tend to agree, except that "canonical" and "absolute" aren't the same,
so a canonical path _can_ start with a series of "../" sequences.
>b) Right now hardly any of our APIs document if they want a canonical
> URL or not. For the most part the svn_path_* commands require a
> canonical form, with the exception of svn_path_canonicalize and
> svn_path_internal_style. svn_client_import() also documents that
> paths need not be in canonical form. Other than that it's not
> documented.
>
>
I think it's pretty much obvious that all our APIs, except the two you
mention, require a canonical path (or URL) encoded in UTF-8. I'd
actually go as far as to require the coding to be in Normalized Form C,
for consistency -- not that we can guarantee that even in our own client
programs right now.
> This ends up creating the problems like we're seeing reported in this
> bug. Ultimately this bug is a result of the ra lib assuming it has a
> canonical path and passing that into svn_path_join, which also
> assumes it has a canonical path, and as a result ends up returning
> a path that is not canonical and fails the assertion, even though
> it is documented as always returning a canonical path.
>
> I believe any library below svn_client is already assuming that it is
> receiving canonical paths. Therefor, my answer is svn_client and
> the two functions in svn_path are the only APIs that should accept
> non-canonical paths.
>
>c) I tend to think that all APIs should produce canonical paths. If we
> don't then we'll run into situations where someone doesn't realize
> that some API produced a non-canonical path and use it with something
> that requires one.
>
>
"Principle of least surprise" here. Ah, except svn_path_local_style. :-)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue #1901 (double slashes screw things): Patch, and some strategy questions
Posted by Ben Reser <be...@reser.org>.
On Sat, Jul 03, 2004 at 07:28:08AM -0400, Josh Pieper wrote:
> Yes, this is a symptom of a larger problem, namely that
> svn_path_canonicalize doesn't return a canonicalized path. Canonical
> would mean that any two input paths that referenced the same file
> should have the same output path (at least relative to the same root).
> svn_path_canonicalize should really behave more like
> svn_path_get_absolute, except without the requirement that the file or
> path actually exist on disk. I'm working on it now.
>
> It seems that in addition to this problem, there may also be
> sub-commands that don't canonicalize their paths/URLs before using
> them. I'll see what can be done about that too afterwards.
Before we can really fix this we need to answer the following questions:
a) What constitutes a "canonical" path?
b) At what level does the API require a "canonical" path?
c) At what level is the API required to produce a "canonical" path?
Without these answers, we can't really fix this.
Here are my answers:
a) Right now we're using the following definition:
Is not ".", Does not end in "/".
If we're going to use the same rules for canonicalizing URLs we need
keep a few things in mind. It is up to the server, how to interpret
the path portion of the URL. In our case we have two servers that
we have to mainly worry about and then file:/// which is interprted
by the OS.
We know that generally all of them interpret the following things in
special ways:
//
/./
/../
We also know that // may in some cases, though probably rare a
different path in one of our servers (Apache).
However, trying to permit // looks like it's going to end up being a
real hassle. Using a path with // would already be problematic, and
we haven't seen any users complaining because their paths with // in
them don't work. (By this I mean a path where
http://www.example.com/whatever//foo differs from
http://www.example.com/whatever/foo in what the server returns, not
people using // on accident as the issues we're talking with deal
with.
As a result I'm inclined to think (despite my previous objections)
that a canonical path does not contain the following things:
Is not equal to "."
Does not end in "/"
Does not contain "//", "/./" or "/../".
b) Right now hardly any of our APIs document if they want a canonical
URL or not. For the most part the svn_path_* commands require a
canonical form, with the exception of svn_path_canonicalize and
svn_path_internal_style. svn_client_import() also documents that
paths need not be in canonical form. Other than that it's not
documented.
This ends up creating the problems like we're seeing reported in this
bug. Ultimately this bug is a result of the ra lib assuming it has a
canonical path and passing that into svn_path_join, which also
assumes it has a canonical path, and as a result ends up returning
a path that is not canonical and fails the assertion, even though
it is documented as always returning a canonical path.
I believe any library below svn_client is already assuming that it is
receiving canonical paths. Therefor, my answer is svn_client and
the two functions in svn_path are the only APIs that should accept
non-canonical paths.
c) I tend to think that all APIs should produce canonical paths. If we
don't then we'll run into situations where someone doesn't realize
that some API produced a non-canonical path and use it with something
that requires one.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue #1901 (double slashes screw things): Patch, and some strategy questions
Posted by Ben Reser <be...@reser.org>.
On Sat, Jul 03, 2004 at 10:51:40PM +0200, Peter N. Lundblad wrote:
> Hmmm... I should read my mail inorder... Don't forget Ben Reser's post
> aobut (see the reference in his mail). Maybe it is better to learn the
> other path routines about multiple slashes then? Still, normalizing away .
> and .. might be a good idea.
Josh and I discussed this on IRC. Needing to support multiple slashes
in a URL would require a highly unusual configuration. The cost of
supporting such a configuration, would likely be lots of edge case bugs
of the more common configurations that we know most people are using and
lots of time writing special logic to deal with accepting multiple
slashes.
Josh says he has the code to fix canonicalize done, he just needs to get
around to committing it. So that's what we're going to do. Unless
someone has objections to this.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue #1901 (double slashes screw things): Patch, and some
strategy questions
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sat, 3 Jul 2004, Josh Pieper wrote:
> Klaus Rennecke wrote:
> > Ben Reser wrote:
> >
> > >[...]
> > >
> > >We need to accept double slashes. See Issue #1779 and my comments on it
> > >in:
> > ><20...@occipital.brain.org>
> > >http://www.contactor.se/~dast/svn/archive-2004-03/0558.shtml
> > >
> > >The correct fix is to fix whatever is segfault when it encouters
> > >multiple slashes...
> > >
> >
> > As stated in an earlier followup
> > http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=69409 I am
> > pretty convinced that this issue is actually part of a more general
> > problem. There should be an algorithm floting around on my desktop
> > somewhere, but I don't have the time to port it from Java and check
> > legal at the moment.
> >
> > Sorry if I'm repeating myself, but I think this may turn ugly if you fix
> > the issue in small increments every time someone finds a new angle to
> > this. See <http://rfc.net/rfc2396.html#s5.2.>
>
> Yes, this is a symptom of a larger problem, namely that
> svn_path_canonicalize doesn't return a canonicalized path. Canonical
Hmmm... I should read my mail inorder... Don't forget Ben Reser's post
aobut (see the reference in his mail). Maybe it is better to learn the
other path routines about multiple slashes then? Still, normalizing away .
and .. might be a good idea.
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue #1901 (double slashes screw things): Patch, and some strategy questions
Posted by Josh Pieper <jj...@pobox.com>.
Klaus Rennecke wrote:
> Ben Reser wrote:
>
> >[...]
> >
> >We need to accept double slashes. See Issue #1779 and my comments on it
> >in:
> ><20...@occipital.brain.org>
> >http://www.contactor.se/~dast/svn/archive-2004-03/0558.shtml
> >
> >The correct fix is to fix whatever is segfault when it encouters
> >multiple slashes...
> >
>
> As stated in an earlier followup
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=69409 I am
> pretty convinced that this issue is actually part of a more general
> problem. There should be an algorithm floting around on my desktop
> somewhere, but I don't have the time to port it from Java and check
> legal at the moment.
>
> Sorry if I'm repeating myself, but I think this may turn ugly if you fix
> the issue in small increments every time someone finds a new angle to
> this. See <http://rfc.net/rfc2396.html#s5.2.>
Yes, this is a symptom of a larger problem, namely that
svn_path_canonicalize doesn't return a canonicalized path. Canonical
would mean that any two input paths that referenced the same file
should have the same output path (at least relative to the same root).
svn_path_canonicalize should really behave more like
svn_path_get_absolute, except without the requirement that the file or
path actually exist on disk. I'm working on it now.
It seems that in addition to this problem, there may also be
sub-commands that don't canonicalize their paths/URLs before using
them. I'll see what can be done about that too afterwards.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue #1901 (double slashes screw things): Patch, and some strategy
questions
Posted by Klaus Rennecke <kr...@tigris.org>.
Ben Reser wrote:
> [...]
>
>We need to accept double slashes. See Issue #1779 and my comments on it
>in:
><20...@occipital.brain.org>
>http://www.contactor.se/~dast/svn/archive-2004-03/0558.shtml
>
>The correct fix is to fix whatever is segfault when it encouters
>multiple slashes...
>
As stated in an earlier followup
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=69409 I am
pretty convinced that this issue is actually part of a more general
problem. There should be an algorithm floting around on my desktop
somewhere, but I don't have the time to port it from Java and check
legal at the moment.
Sorry if I'm repeating myself, but I think this may turn ugly if you fix
the issue in small increments every time someone finds a new angle to
this. See <http://rfc.net/rfc2396.html#s5.2.>
/Klaus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue #1901 (double slashes screw things): Patch, and some strategy questions
Posted by Ben Reser <be...@reser.org>.
On Sun, Jun 20, 2004 at 05:07:53PM +0300, Shlomi Fish wrote:
> Hi all!
>
> Attached is a proposed patch to Issue #1901:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=1901
>
> The issue concerns the fact that copying two URLs with double slashes in
> certain places, can cause Subversion to crash with an assertion (and possibly
> other problems as reported in the comments). The patch fixes them by ensuring
> that double slashes are removed at the beginning of the call to
> svn_client_copy() and friends.
>
> A possible problem is that: (which I wrote in the Issue Page):
We need to accept double slashes. See Issue #1779 and my comments on it
in:
<20...@occipital.brain.org>
http://www.contactor.se/~dast/svn/archive-2004-03/0558.shtml
The correct fix is to fix whatever is segfault when it encouters
multiple slashes...
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue #1901 (double slashes screw things): Patch, and some
strategy questions
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sun, 20 Jun 2004, Shlomi Fish wrote:
> Hi all!
>
> Attached is a proposed patch to Issue #1901:
>
Nice to see you're working on this.
> A possible problem is that: (which I wrote in the Issue Page):
>
> <<<
> Well, the patch I sent above corrects the problem, but I'm not sure if in the
> right way. It does so, by filtering out double slashes from URLs inputted to
> the svn_client_copy() and svn_client_move() functions. So, the bug still
> exists in the lower levels, but it isn't encountered this way.
>
> We should decide whether we can deal with double slashes in URLs (or in paths)
> when being inputted at every stage, or that the routines can be expected to
> fail if given such input.
> >>>
>
I don't think this is the correct solution. I think you are fixing
symptoms, not causes. Actually, we need to be careful not to treat URLs as
normalized paths.
> Fixes Issue #1901 ( Crash in copy command with URL with double slashes ).
>
> * include/svn_path.h
> Added the declaration of svn_path_url_remove_multiple_slashes().
>
I think this is a too specific function name. We may want to do other URI
normalization as well, such as canonicalizing %3f to %3F and such. When
we've decided on this, it should be done consistently in some layer.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Issue #1901 (double slashes screw things): Patch, and some strategy
questions
Posted by Klaus Rennecke <kr...@tigris.org>.
Shlomi Fish wrote:
> Hi all!
>
> Attached is a proposed patch to Issue #1901:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=1901
>
> The issue concerns the fact that copying two URLs with double slashes
> in certain places, can cause Subversion to crash with an assertion [...]
Hmm this looks more like a general normalization problem. Two similar,
but distinct cases, recipe with trunk as of today:
tukan:[kre]> svn --version
svn, Version 1.1.0 (dev build)
übersetzt Jun 20 2004, 18:52:50
[...snip...]
tukan:[kre]> svnadmin create /tmp/1901
tukan:[kre]> svn mkdir -m "" file:///tmp/1901/branches
Revision 1 übertragen.
tukan:[kre]> svn mkdir -m "" file:///tmp/1901/branches/branch1
Revision 2 übertragen.
tukan:[kre]> svn copy -m "" file:///tmp/1901/branches/branch1 file:///tmp/1901/branches/branch1/../branch2
subversion/libsvn_repos/commit.c:114: (apr_err=160028)
svn: Out of date: '/branches/branch1/..' in transaction '3'
tukan:[kre]> svn copy -m "" file:///tmp/1901/branches/branch1 file:///tmp/1901/branches/./branch3
svn: subversion/libsvn_subr/path.c:157: svn_path_join: Zusicherung »is_canonical (component, clen)« nicht erfüllt.
Abgebrochen
What is the "Out of date..." message supposed to tell the user?
Some scripts and make-like tools tend to create paths with ../something,
I think it would be good to support them by normalizing the URL path in
a defined manner, like in RFC 2396 http://rfc.net/rfc2396.html#s5.2.
section 5.2. steps 6c-6g
But I don't know on what level that should be done. On the client side,
initial command line processing, seems right to get most consistency of
client side operations with server side, but that's just a feeling. At
least that would allow early error-out for cases of 6g (extra /../
without a preceding segment).
/Klaus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org