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

Re: Bug: IP address bogusly interpreted as peg revision

From: Daniel Shahaf <d.s_at_daniel.shahaf.co.il>
Date: Mon, 26 May 2008 09:14:30 +0300 (Jerusalem Daylight Time)

Troy Curtis Jr wrote on Sun, 25 May 2008 at 21:45 -0500:
> On Sun, May 25, 2008 at 8:39 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> > "Troy Curtis Jr" <troycurtisjr_at_gmail.com> writes:
> >> You know after thinking about it I could "fix" this behavior. I'm
> >> working on my revised patch right now and I think the trailing slash
> >> workaround would work if I returned "@" for no peg revision found
> >> instead of "" in my new fangled svn_opt__split_arg_at_peg_revision()
> >> function. This would mean that every single target coming out of the
> >> svn_client_args_to_target_array() would have a peg revision, but some
> >> of them would be blank.
> >
> > What's the connection betweening return "@" instead of "" and making
> > trailing slashes prevent peg-revision interpretation?
> >
> > I'd hate to see an improvement to our peg revision interpretation affect
> > APIs that way. Why can't we say "anything appearing before the last
> > slash in a path is not a peg revision" without having the API effect you
> > describe above?
> >

Maybe append an "@" to the canonicalized path only if the latter contains
an "@"? It is not necessary otherwise.


> The issue is where the canonicalization happens and when the peg
> revision is actually parsed. When the paths are canonicalization
> happens the peg revision is split off, the path is canonicallized and
> the peg is stuck back on for later processing. Unfortunately a
> trailing slash is removed during canonicallization, so during the
> later peg processing it is not there to 'escape' the non-peg '@' sign.
> For all later interpretation a trailing '@' symbol and no @ symbol at
> all mean the same thing, no specified peg revision. By having
> svn_opt__split_arg_at_peg_revision() return "@" for an empty peg
> revision (instead of the empty string) you can always get the desired
> behavior. In the case of a trailing slash on a target, you are
> effectively replacing the trailing slash "escaping" method (which is
> not canonical) with the "real" trailing '@' escaping method. But you
> do guarantee that all targets will have an '@' specifier, but most of
> them will not have anything following them.
> Taking the some of the paths from the test_args_to_target_array() function in
> subversion/tests/libsvn_client/client-test.c and adding a couple more:
> Current behavior:
> "." ""
> "._at_BASE" "@BASE"
> "foo///bar" "foo/bar"
> "http://a//b////" "http://a/b"
> "http://a///b@27" "http://a/b@27"
> "http://a/b//@COMMITTED" "http://a/b@COMMITTED"
> "foo@///bar" "foo@/bar"
> "foo_at_HEAD///bar" "foo_at_HEAD/bar"
> Adding:
> "svn+ssh://svn@" "svn+ssh://svn@"
> "svn+ssh://svn@" "svn+ssh://svn@"
> "svn+ssh://svn@" "svn+ssh://svn@"
> Behavior if we always use '@' for no peg specified:
> "." "@"
> "._at_BASE" "@BASE"
> "foo///bar" "foo/bar@"
> "http://a//b////" "http://a/b@"
> "http://a///b@27" "http://a/b@27"
> "http://a/b//@COMMITTED" "http://a/b@COMMITTED"
> "foo///@bar_at_HEAD" "foo/@bar_at_HEAD"
> "foo@///bar" "foo@/bar@"
> "foo_at_HEAD///bar" "foo_at_HEAD/bar@"
> Adding:
> "svn+ssh://svn@" "svn+ssh://svn@"
> "svn+ssh://svn@" "svn+ssh://svn@"
> "svn+ssh://svn@" "svn+ssh://svn@"
> All of the downstream APIs don't have to change and in fact don't have to know
> about this modification. A trailing '@' IS a valid peg revision. If it is
> there the APIs can take it. If not, it is handled just the same, unspecified.
> This isn't really a change in our specification at the APIs, just in how we
> interpret the user specified args. It is probably valid for a user to believe
> a trailing slash should tell Subversion that the characters before it are a
> target and NOT a peg revision, despite any '@' symbols that may be in it.
> Troy

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-26 08:14:45 CEST

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.