You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Madan US <ma...@collab.net> on 2005/10/04 20:53:59 UTC
[PATCH] Issue 2318 : Inconsistent behavior with trailing '/'
Hi,
Pl. find attached the fix for issue #2318.
Regards,
Madan.
Re: [PATCH] Issue 2318 : Inconsistent behavior with trailing '/'
Posted by kf...@collab.net.
Madan U Sreenivasan <ma...@collab.net> writes:
> Okay, I will update the issue and ask Eli/Karl for their comments...
> what say?
I have responded in the issue, in
http://subversion.tigris.org/issues/show_bug.cgi?id=2318#desc9
saying:
> The documented (official, recommended, canonical, one true, etc)
> way to quote a "@" in a path is to put a trailing "@" on that path.
> This is because the empty peg revision defaults to HEAD, and since
> only the last "@" in a path is significant for peg revision
> purposes, a trailing "@" has the desired effect.
>
> Is there still a bug here? If so, is it a documentation bug, or a
> code bug?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Issue 2318 : Inconsistent behavior with trailing '/'
Posted by Madan U Sreenivasan <ma...@collab.net>.
On Thu, 2005-10-06 at 01:57, Philip Martin wrote:
> "Madan US" <ma...@collab.net> writes:
> >>>> I think svn_path_canonicalize is the wrong place to be handling '@'
> >>>> for peg revisions. All peg handling should happen in opt.c.
> >>>
> >>> We are not handling the peg revisions here. We are only adjusting the
> >>> input path so that a filename with @ and followed by a trailing / would
> >>> be
> >>> recognised by the code that handles peg revisions (opt.c?) ... in this
> >>> case, by replacing the trailing / with an @, so that
> >>> svn_opt_parse_path()
> >>> recognises the @ in the filename and not as an indicator for a peg
> >>> revision...
> >>
> >> It's possible that there are clients that don't use the '@nnn' syntax
> >> for peg revisions, it's a bit of a hack after all. Those clients will
> >> want to use svn_path_canonicalize so that function cannot treat '@' as
> >> special.
> > .... and those client will use libsvn_subr?
> They may well use svn_path_canonicalize.
you are right.
>
> > which takes the @ as a peg
> > revision marker?
>
> At present only svn_opt_parse_path in opt.c hadles '@' as a peg
> revision. Your patch spreads that special behaviour into a second
> function in a different file, that's bad.
Yes, its bad. Thanks for pointing out.
>
> I think it's a mistake for svn_path_canonicalize to treat '@' as
> special. I think it's a mistake to try to make a trailing '/' behave
> in the same way as a trailing '@'. If there are circumstances when a
> trailing '@' doesn't work then it would be better to fix them.
hmmm... I was thinking of taking this logic into svn_opt_parse_path()...
but as I mentioned in my reply to Lundblad, svn_opt_parse_path() would
never see the trailing '/' that the user entered...
Okay, I will update the issue and ask Eli/Karl for their comments...
what say?
Regards,
Madan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Issue 2318 : Inconsistent behavior with trailing '/'
Posted by Philip Martin <ph...@codematters.co.uk>.
"Madan US" <ma...@collab.net> writes:
>> "Madan US" <ma...@collab.net> writes:
>>
>>>> Madan U Sreenivasan <ma...@collab.net> writes:
>>>>
>>>>> On Wed, 2005-10-05 at 02:56, Philip Martin wrote:
>>>>>> "Madan US" <ma...@collab.net> writes:
>>>>>> >
>>>>>> > * subversion/libsvn_subr/path.c
>>>>>> > (svn_path_canonicalize): Modified to replace the trailing
>>>>>> slash
>>>>>> > in the filename to @ if the last segment of the file path
>>>>>> > contained an @.
>>>>
>>>> I think svn_path_canonicalize is the wrong place to be handling '@'
>>>> for peg revisions. All peg handling should happen in opt.c.
>>>
>>> We are not handling the peg revisions here. We are only adjusting the
>>> input path so that a filename with @ and followed by a trailing / would
>>> be
>>> recognised by the code that handles peg revisions (opt.c?) ... in this
>>> case, by replacing the trailing / with an @, so that
>>> svn_opt_parse_path()
>>> recognises the @ in the filename and not as an indicator for a peg
>>> revision...
>>
>> It's possible that there are clients that don't use the '@nnn' syntax
>> for peg revisions, it's a bit of a hack after all. Those clients will
>> want to use svn_path_canonicalize so that function cannot treat '@' as
>> special.
> .... and those client will use libsvn_subr?
They may well use svn_path_canonicalize.
> which takes the @ as a peg
> revision marker?
At present only svn_opt_parse_path in opt.c hadles '@' as a peg
revision. Your patch spreads that special behaviour into a second
function in a different file, that's bad.
> am not too sure...but maybe its just my ignorance...
>>
>>> Can you think of a better way to handle this in opt.c? If so, pl. let me
>>> know...
>>
>> I don't understand the issue: I'd like a description of the behaviour
>> you are trying to implement.
> Pl. see the tests I have added to path_test.c. It would clarify a little..
> anyways, I have elaborated my understanding below...
>
>> Why can't we simply require the user to input a trailing '@' instead
>> of a trailing '/'? When did trailing '/' become special?
> Yes..That was the requirement for issue #2317, which r15289 accompolished...
As far as I can see r15289 make a trailing '@' work, it doesn't make a
trailing '/' special.
> My understanding of 2318 is as following....
>
> A filename with a peg revision could be followed by a trailing slash as in
> file:///path/to/filewith@marker/ and expect svn to understand that
> filewith@marker is actually a filename and not a peg revisioned file.
I think that's silly.
> Similar to the way file:///path/to/filewith@marker@ will be treated (issue
> #2317)
That's the correct way to do it, why should we invent another?
> The rational behind the request was the following. I think its a little
> shallow myself....
>
> file:///path/to/filename/ is treated as if filename is a file(and not a
> dir due to the trailing slash)
> but
> file:///path/to/filewith@mark/ errors out saying that 'mark' is not a
> valid revision(and hence looks like filewith@mark is not treated as a
> filename as a whole)
>
> The reality is
> file:///path/to/file/ is treated as file:///path/to/file
> ...thanks to svn_path_canonocalize(). Similarly...
> file:///path/to/filewith@mark/ is treated as file:///path/to/filewith@mark
> and hence errors out saying that 'mark' is not a valid revision.
>
> Since its svn_path_canonicalize() that causes the symptom in the first
> place, I have tried to make it understand (a little intelligently) that
> the user might have used the trailing / intentionally - if the last
> segment of the filename contains an @ symbol (The trailing slash
> wouldnt make sense if what comes after that @ is a revision number).
> Hence the behavior of using a trailing / should be treated as if an
> trailing @ was present.
>
> Questions? Swearing? ;)
I think it's a mistake for svn_path_canonicalize to treat '@' as
special. I think it's a mistake to try to make a trailing '/' behave
in the same way as a trailing '@'. If there are circumstances when a
trailing '@' doesn't work then it would be better to fix them.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Issue 2318 : Inconsistent behavior with trailing '/'
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Thu, 6 Oct 2005, Madan U Sreenivasan wrote:
> On Thu, 2005-10-06 at 01:40, Peter N. Lundblad wrote:
> > On Wed, 5 Oct 2005, Madan US wrote:
> [snip]
> > > Since its svn_path_canonicalize() that causes the symptom in the first
> > > place, I have tried to make it understand (a little intelligently) that
> > > the user might have used the trailing / intentionally - if the last
> > > segment of the filename contains an @ symbol (The trailing slash
> > > wouldnt make sense if what comes after that @ is a revision number).
> > > Hence the behavior of using a trailing / should be treated as if an
> > > trailing @ was present.
> > >
> > I haven't looked at this in detail, but to me it sounds like the path is
> > canonicalized *before* the peg revision is stripped. Couldn't you just
> > reverse the order? (Just a suggestion)
> Yes, and its called in the following sequence...
> svn_cl__proplist()->svn_opt_args_to_target_array2()->svn_path_canonicalize()
>
> peg revision processing happens here...
> svn_cl__proplist()->svn_opt_parse_path()
>
> where the former is (rightly) done before the latter. So, we cant
> reverse the order.. :(
>
I think it is wrong for svn_opt_args_to_target_array2 to canonicalize the
paths, because they aren't paths, they are paths plus an optional peg
specification. There also is code to "canonicalize the case", which
obviously doesn't work if there is an @rev at the end of the "path".
Regarding the Issue at hand, it seems hackish, as philip pointed out, to
use a trailing slash to support filenames with @. Why don't we have an
escaping mechanism for this? (Rethorical question, of course.)
Thanks,
//Peter
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Issue 2318 : Inconsistent behavior with trailing '/'
Posted by Madan U Sreenivasan <ma...@collab.net>.
On Thu, 2005-10-06 at 01:40, Peter N. Lundblad wrote:
> On Wed, 5 Oct 2005, Madan US wrote:
[snip]
> > Since its svn_path_canonicalize() that causes the symptom in the first
> > place, I have tried to make it understand (a little intelligently) that
> > the user might have used the trailing / intentionally - if the last
> > segment of the filename contains an @ symbol (The trailing slash
> > wouldnt make sense if what comes after that @ is a revision number).
> > Hence the behavior of using a trailing / should be treated as if an
> > trailing @ was present.
> >
> I haven't looked at this in detail, but to me it sounds like the path is
> canonicalized *before* the peg revision is stripped. Couldn't you just
> reverse the order? (Just a suggestion)
Yes, and its called in the following sequence...
svn_cl__proplist()->svn_opt_args_to_target_array2()->svn_path_canonicalize()
peg revision processing happens here...
svn_cl__proplist()->svn_opt_parse_path()
where the former is (rightly) done before the latter. So, we cant
reverse the order.. :(
Pl. do let me know if theres something am missing...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Issue 2318 : Inconsistent behavior with trailing '/'
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 5 Oct 2005, Madan US wrote:
> > It's possible that there are clients that don't use the '@nnn' syntax
> > for peg revisions, it's a bit of a hack after all. Those clients will
> > want to use svn_path_canonicalize so that function cannot treat '@' as
> > special.
> .... and those client will use libsvn_subr? which takes the @ as a peg
> revision marker? am not too sure...but maybe its just my ignorance...
> >
The @rrr is a command line client thing. The peg revision part is not a
part of the path. A GUI client could have other means of specifyihng a peg
revision.
> A filename with a peg revision could be followed by a trailing slash as in
> file:///path/to/filewith@marker/ and expect svn to understand that
> filewith@marker is actually a filename and not a peg revisioned file.
> Similar to the way file:///path/to/filewith@marker@ will be treated (issue
> #2317)
>
> The rational behind the request was the following. I think its a little
> shallow myself....
>
> file:///path/to/filename/ is treated as if filename is a file(and not a
> dir due to the trailing slash)
> but
> file:///path/to/filewith@mark/ errors out saying that 'mark' is not a
> valid revision(and hence looks like filewith@mark is not treated as a
> filename as a whole)
>
> The reality is
> file:///path/to/file/ is treated as file:///path/to/file
> ...thanks to svn_path_canonocalize(). Similarly...
> file:///path/to/filewith@mark/ is treated as file:///path/to/filewith@mark
> and hence errors out saying that 'mark' is not a valid revision.
>
> Since its svn_path_canonicalize() that causes the symptom in the first
> place, I have tried to make it understand (a little intelligently) that
> the user might have used the trailing / intentionally - if the last
> segment of the filename contains an @ symbol (The trailing slash
> wouldnt make sense if what comes after that @ is a revision number).
> Hence the behavior of using a trailing / should be treated as if an
> trailing @ was present.
>
I haven't looked at this in detail, but to me it sounds like the path is
canonicalized *before* the peg revision is stripped. Couldn't you just
reverse the order? (Just a suggestion)
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Issue 2318 : Inconsistent behavior with trailing '/'
Posted by Madan US <ma...@collab.net>.
> "Madan US" <ma...@collab.net> writes:
>
>>> Madan U Sreenivasan <ma...@collab.net> writes:
>>>
>>>> On Wed, 2005-10-05 at 02:56, Philip Martin wrote:
>>>>> "Madan US" <ma...@collab.net> writes:
>>>>> >
>>>>> > * subversion/libsvn_subr/path.c
>>>>> > (svn_path_canonicalize): Modified to replace the trailing
>>>>> slash
>>>>> > in the filename to @ if the last segment of the file path
>>>>> > contained an @.
>>>
>>> I think svn_path_canonicalize is the wrong place to be handling '@'
>>> for peg revisions. All peg handling should happen in opt.c.
>>
>> We are not handling the peg revisions here. We are only adjusting the
>> input path so that a filename with @ and followed by a trailing / would
>> be
>> recognised by the code that handles peg revisions (opt.c?) ... in this
>> case, by replacing the trailing / with an @, so that
>> svn_opt_parse_path()
>> recognises the @ in the filename and not as an indicator for a peg
>> revision...
>
> It's possible that there are clients that don't use the '@nnn' syntax
> for peg revisions, it's a bit of a hack after all. Those clients will
> want to use svn_path_canonicalize so that function cannot treat '@' as
> special.
.... and those client will use libsvn_subr? which takes the @ as a peg
revision marker? am not too sure...but maybe its just my ignorance...
>
>> Can you think of a better way to handle this in opt.c? If so, pl. let me
>> know...
>
> I don't understand the issue: I'd like a description of the behaviour
> you are trying to implement.
Pl. see the tests I have added to path_test.c. It would clarify a little..
anyways, I have elaborated my understanding below...
> Why can't we simply require the user to input a trailing '@' instead
> of a trailing '/'? When did trailing '/' become special?
Yes..That was the requirement for issue #2317, which r15289 accompolished...
My understanding of 2318 is as following....
A filename with a peg revision could be followed by a trailing slash as in
file:///path/to/filewith@marker/ and expect svn to understand that
filewith@marker is actually a filename and not a peg revisioned file.
Similar to the way file:///path/to/filewith@marker@ will be treated (issue
#2317)
The rational behind the request was the following. I think its a little
shallow myself....
file:///path/to/filename/ is treated as if filename is a file(and not a
dir due to the trailing slash)
but
file:///path/to/filewith@mark/ errors out saying that 'mark' is not a
valid revision(and hence looks like filewith@mark is not treated as a
filename as a whole)
The reality is
file:///path/to/file/ is treated as file:///path/to/file
...thanks to svn_path_canonocalize(). Similarly...
file:///path/to/filewith@mark/ is treated as file:///path/to/filewith@mark
and hence errors out saying that 'mark' is not a valid revision.
Since its svn_path_canonicalize() that causes the symptom in the first
place, I have tried to make it understand (a little intelligently) that
the user might have used the trailing / intentionally - if the last
segment of the filename contains an @ symbol (The trailing slash
wouldnt make sense if what comes after that @ is a revision number).
Hence the behavior of using a trailing / should be treated as if an
trailing @ was present.
Questions? Swearing? ;)
oh, btw, I have attached the patch with new tests in path-test.c.
Regards,
Madan.
Re: [PATCH] Issue 2318 : Inconsistent behavior with trailing '/'
Posted by Philip Martin <ph...@codematters.co.uk>.
"Madan US" <ma...@collab.net> writes:
>> Madan U Sreenivasan <ma...@collab.net> writes:
>>
>>> On Wed, 2005-10-05 at 02:56, Philip Martin wrote:
>>>> "Madan US" <ma...@collab.net> writes:
>>>> >
>>>> > * subversion/libsvn_subr/path.c
>>>> > (svn_path_canonicalize): Modified to replace the trailing slash
>>>> > in the filename to @ if the last segment of the file path
>>>> > contained an @.
>>
>> I think svn_path_canonicalize is the wrong place to be handling '@'
>> for peg revisions. All peg handling should happen in opt.c.
>
> We are not handling the peg revisions here. We are only adjusting the
> input path so that a filename with @ and followed by a trailing / would be
> recognised by the code that handles peg revisions (opt.c?) ... in this
> case, by replacing the trailing / with an @, so that svn_opt_parse_path()
> recognises the @ in the filename and not as an indicator for a peg
> revision...
It's possible that there are clients that don't use the '@nnn' syntax
for peg revisions, it's a bit of a hack after all. Those clients will
want to use svn_path_canonicalize so that function cannot treat '@' as
special.
> Can you think of a better way to handle this in opt.c? If so, pl. let me
> know...
I don't understand the issue: I'd like a description of the behaviour
you are trying to implement.
Why can't we simply require the user to input a trailing '@' instead
of a trailing '/'? When did trailing '/' become special?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Issue 2318 : Inconsistent behavior with trailing '/'
Posted by Madan US <ma...@collab.net>.
> Madan U Sreenivasan <ma...@collab.net> writes:
>
>> On Wed, 2005-10-05 at 02:56, Philip Martin wrote:
>>> "Madan US" <ma...@collab.net> writes:
>>> >
>>> > * subversion/libsvn_subr/path.c
>>> > (svn_path_canonicalize): Modified to replace the trailing slash
>>> > in the filename to @ if the last segment of the file path
>>> > contained an @.
>
> I think svn_path_canonicalize is the wrong place to be handling '@'
> for peg revisions. All peg handling should happen in opt.c.
We are not handling the peg revisions here. We are only adjusting the
input path so that a filename with @ and followed by a trailing / would be
recognised by the code that handles peg revisions (opt.c?) ... in this
case, by replacing the trailing / with an @, so that svn_opt_parse_path()
recognises the @ in the filename and not as an indicator for a peg
revision...
Can you think of a better way to handle this in opt.c? If so, pl. let me
know...
[snip]
>
>> I did notice the change to tests/libsvn_subr/opt-test.c made for
>> r15289. I couldnt figure out how it works.
>
> It's fairly simple, it's just an array of inputs to, and expected
> outputs from, svn_opt_parse_path.
Oh, that was my understanding too... would submit the patch again with
this done... thanks for the input...
Regards,
Madan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Issue 2318 : Inconsistent behavior with trailing '/'
Posted by Philip Martin <ph...@codematters.co.uk>.
Madan U Sreenivasan <ma...@collab.net> writes:
> On Wed, 2005-10-05 at 02:56, Philip Martin wrote:
>> "Madan US" <ma...@collab.net> writes:
>> >
>> > * subversion/libsvn_subr/path.c
>> > (svn_path_canonicalize): Modified to replace the trailing slash
>> > in the filename to @ if the last segment of the file path
>> > contained an @.
I think svn_path_canonicalize is the wrong place to be handling '@'
for peg revisions. All peg handling should happen in opt.c.
>> > * subversion/test/clients/cmdline/basic_tests.py
>> > (basic_peg_revision): Modified to check for the @ sign and the
>> > trailing slash combination.
>>
>> Your test doesn't really check your new code since it doesn't use an
>> '@' sign. You should probably write more complete tests, i.e. all
>> combinations, in test_canonical in tests/libsvn_subr/path-test.c.
> I think it does check the new code. It was run before(failure) and
> after(success) the changes... Pl. refer to the filename variable in
> basic_peg_revision() in basic_tests.py.
I was wrong.
> I did notice the change to tests/libsvn_subr/opt-test.c made for
> r15289. I couldnt figure out how it works.
It's fairly simple, it's just an array of inputs to, and expected
outputs from, svn_opt_parse_path.
> Am afraid I dont know much
> about tests/libsvn_subr/path-test.c either.
> Lemme read about it. In the meanwhile, if you could give me any
> pointers towards this, it would be great. thx.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Issue 2318 : Inconsistent behavior with trailing '/'
Posted by Madan U Sreenivasan <ma...@collab.net>.
On Wed, 2005-10-05 at 02:56, Philip Martin wrote:
> "Madan US" <ma...@collab.net> writes:
>
> > Index: subversion/tests/clients/cmdline/basic_tests.py
> > ===================================================================
> > --- subversion/tests/clients/cmdline/basic_tests.py (revision 16440)
> > +++ subversion/tests/clients/cmdline/basic_tests.py (working copy)
> > @@ -1610,7 +1610,13 @@
> > output, errlines = svntest.actions.run_and_verify_svn(None, ["xyz\n"], [],
> > 'cat', url+'@')
> >
> > + # With the trailing "/", expect success.
> > + output, errlines = svntest.actions.run_and_verify_svn(None, ["xyz\n"], [],
> > + 'cat', wc_file+'/')
> > + output, errlines = svntest.actions.run_and_verify_svn(None, ["xyz\n"], [],
> > + 'cat', url+'/')
> >
> > +
> > #----------------------------------------------------------------------
> > ########################################################################
> >
> > Issue #2318: Inconsistent behavior with trailing '/'
> >
> > * subversion/libsvn_subr/path.c
> > (svn_path_canonicalize): Modified to replace the trailing slash
> > in the filename to @ if the last segment of the file path
> > contained an @.
> > * subversion/test/clients/cmdline/basic_tests.py
> > (basic_peg_revision): Modified to check for the @ sign and the
> > trailing slash combination.
>
> Your test doesn't really check your new code since it doesn't use an
> '@' sign. You should probably write more complete tests, i.e. all
> combinations, in test_canonical in tests/libsvn_subr/path-test.c.
I think it does check the new code. It was run before(failure) and
after(success) the changes... Pl. refer to the filename variable in
basic_peg_revision() in basic_tests.py.
I did notice the change to tests/libsvn_subr/opt-test.c made for
r15289. I couldnt figure out how it works. Am afraid I dont know much
about tests/libsvn_subr/path-test.c either.
Lemme read about it. In the meanwhile, if you could give me any
pointers towards this, it would be great. thx.
Regards,
Madan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Issue 2318 : Inconsistent behavior with trailing '/'
Posted by Philip Martin <ph...@codematters.co.uk>.
"Madan US" <ma...@collab.net> writes:
> Index: subversion/tests/clients/cmdline/basic_tests.py
> ===================================================================
> --- subversion/tests/clients/cmdline/basic_tests.py (revision 16440)
> +++ subversion/tests/clients/cmdline/basic_tests.py (working copy)
> @@ -1610,7 +1610,13 @@
> output, errlines = svntest.actions.run_and_verify_svn(None, ["xyz\n"], [],
> 'cat', url+'@')
>
> + # With the trailing "/", expect success.
> + output, errlines = svntest.actions.run_and_verify_svn(None, ["xyz\n"], [],
> + 'cat', wc_file+'/')
> + output, errlines = svntest.actions.run_and_verify_svn(None, ["xyz\n"], [],
> + 'cat', url+'/')
>
> +
> #----------------------------------------------------------------------
> ########################################################################
>
> Issue #2318: Inconsistent behavior with trailing '/'
>
> * subversion/libsvn_subr/path.c
> (svn_path_canonicalize): Modified to replace the trailing slash
> in the filename to @ if the last segment of the file path
> contained an @.
> * subversion/test/clients/cmdline/basic_tests.py
> (basic_peg_revision): Modified to check for the @ sign and the
> trailing slash combination.
Your test doesn't really check your new code since it doesn't use an
'@' sign. You should probably write more complete tests, i.e. all
combinations, in test_canonical in tests/libsvn_subr/path-test.c.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org