You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Sergey A. Lipnevich" <se...@optimaltec.com> on 2003/08/04 06:52:58 UTC
Neon 0.24 testing
Hi All,
Could somebody please look at the following errors for basic_tests.py
#1? First of all, "old-style" (pre 0.24) callbacks, "startelm" and
"endelm" in props.c and fetch.c (I'm talking about libsvn_ra_dav)
sometimes return value 1, which is not defined by Neon interface. What
is defined is -1 (invalid XML) or -2 (decline element). If I treat
return 1 as error, I get test failure:
----
subversion/libsvn_ra_dav/props.c:580: (apr_err=20014)
svn: Error string not specified yet
svn: failed to find label "NULL" for url
"/repositories/basic_tests-1/!svn/ver/1/A/mu"
=============================================================
Expected A and actual A are different!
=============================================================
EXPECTED NODE TO BE:
=============================================================
* Node name: A
Path: working_copies/basic_tests-1/A
Contents: None
Properties: {}
Attributes: {'status': 'A '}
Children: 4
=============================================================
ACTUAL NODE FOUND:
=============================================================
* Node name: A
Path: working_copies/basic_tests-1/A
Contents: None
Properties: {}
Attributes: {'status': 'A '}
Children: is a file.
Unequal Types: one Node is a file, the other is a directory
Unequal at node basic_tests-1
Unequal at node working_copies
EXCEPTION: SVNTreeUnequal
FAIL: basic_tests.py 1: basic checkout of a wc
----
...but if I do not treat return 1 as error, I actually get a little
farther, and get this error:
----
subversion/libsvn_wc/lock.c:513: (apr_err=155005)
svn: Working copy not locked
svn: directory not locked (working_copies/basic_tests-1/A/B)
=============================================================
Expected mu and actual mu are different!
=============================================================
EXPECTED NODE TO BE:
=============================================================
* Node name: mu
Path: working_copies/basic_tests-1/A/mu
Contents: None
Properties: {}
Attributes: {'status': 'A '}
Children: is a file.
=============================================================
ACTUAL NODE FOUND:
=============================================================
* Node name: mu
Path: working_copies/basic_tests-1/A/mu
Contents: None
Properties: {}
Attributes: {}
Children: 1
Unequal Types: one Node is a file, the other is a directory
Unequal at node A
Unequal at node basic_tests-1
Unequal at node working_copies
EXCEPTION: SVNTreeUnequal
FAIL: basic_tests.py 1: basic checkout of a wc
----
My qyestion is, how should return 1 be treated? Also, if somebody could
give me a hint with what that error might mean, I'd appreciate it. Thank
you!
Sergey.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Neon 0.24 testing
Posted by kf...@collab.net.
David Waite <ma...@akuma.org> writes:
> Sussman also wanted me to work on this neon branch to revamp the SSL
> support. Should that be indicated in the COMMITTERS file? (as long as
> you are in there...)
I think this new branch counts in "certs branch" :-). Feel free to
change it to "certs branches" if you want, though (just commit).
Thanks for doing this work, btw.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Neon 0.24 testing
Posted by David Waite <ma...@akuma.org>.
Sussman also wanted me to work on this neon branch to revamp the SSL
support. Should that be indicated in the COMMITTERS file? (as long as
you are in there...)
-David Waite
Sergey A. Lipnevich wrote:
> Yes. I mentioned to Ben that I don't have commit privilege, but this
> was in the issue so I guess it didn't reach the target :-)... I have a
> patch that combines MBK work with some more obvious fixing, now I'm up
> against harder part, things like I sent to the list recently. The plan
> is perfect for me, I'm determined to complete this task, albeit I'm
> moving slowly because of lack of UNIX development experience. I'll
> contact you separately about the account.
> Thank you!
>
> Sergey.
>
> kfogel@collab.net wrote:
>
>>"Sergey A. Lipnevich" <se...@optimaltec.com> wrote to Mike Pilato:
>>
>>
>>>Sure, thank you :-)! That's precisely the reason: NE_XML_INVALID
>>>became NE_XML_ABORT in Neon 0.24 without changing the value (-1), and
>>>return value contract has changed for startelm callback
>>>(NE_XML_DECLINE is now 0 instead of -2). And there's no validate
>>>callback anymore, but that's another story...
>>>
>>>
>>
>>Sergey, just to make sure we're working toward the same goal here: Ben
>>Collins-Sussman created this branch for you
>>
>> http://svn.collab.net/repos/svn/branches/neon-0.24/
>>
>>I think the idea is that first we -- uh, you -- get Neon 0.24 working
>>on the branch, then David Waite and you together get cert support
>>working on the branch (since by itself, the upgrade to Neon 0.24 is
>>expected to break certificates in Subversion).
>>
>>Then we fold the branch back into trunk.
>>
>>I'm aware that neither you nor David Waite have promised that all this
>>will happen :-), so this mail is really a question: does this plan
>>sound good to you guys?
>>
>>If it does, mail me your tigris username and a password of your choice
>>(plain text or crypted is fine), and I'll set you up with commit
>>access on that branch.
>>
>>Thanks,
>>-Karl
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Neon 0.24 testing
Posted by "Sergey A. Lipnevich" <se...@optimaltec.com>.
Yes. I mentioned to Ben that I don't have commit privilege, but this was
in the issue so I guess it didn't reach the target :-)... I have a patch
that combines MBK work with some more obvious fixing, now I'm up against
harder part, things like I sent to the list recently. The plan is
perfect for me, I'm determined to complete this task, albeit I'm moving
slowly because of lack of UNIX development experience. I'll contact you
separately about the account.
Thank you!
Sergey.
kfogel@collab.net wrote:
>"Sergey A. Lipnevich" <se...@optimaltec.com> wrote to Mike Pilato:
>
>
>>Sure, thank you :-)! That's precisely the reason: NE_XML_INVALID
>>became NE_XML_ABORT in Neon 0.24 without changing the value (-1), and
>>return value contract has changed for startelm callback
>>(NE_XML_DECLINE is now 0 instead of -2). And there's no validate
>>callback anymore, but that's another story...
>>
>>
>
>Sergey, just to make sure we're working toward the same goal here: Ben
>Collins-Sussman created this branch for you
>
> http://svn.collab.net/repos/svn/branches/neon-0.24/
>
>I think the idea is that first we -- uh, you -- get Neon 0.24 working
>on the branch, then David Waite and you together get cert support
>working on the branch (since by itself, the upgrade to Neon 0.24 is
>expected to break certificates in Subversion).
>
>Then we fold the branch back into trunk.
>
>I'm aware that neither you nor David Waite have promised that all this
>will happen :-), so this mail is really a question: does this plan
>sound good to you guys?
>
>If it does, mail me your tigris username and a password of your choice
>(plain text or crypted is fine), and I'll set you up with commit
>access on that branch.
>
>Thanks,
>-Karl
>
>
Re: Neon 0.24 testing
Posted by kf...@collab.net.
"Sergey A. Lipnevich" <se...@optimaltec.com> wrote to Mike Pilato:
> Sure, thank you :-)! That's precisely the reason: NE_XML_INVALID
> became NE_XML_ABORT in Neon 0.24 without changing the value (-1), and
> return value contract has changed for startelm callback
> (NE_XML_DECLINE is now 0 instead of -2). And there's no validate
> callback anymore, but that's another story...
Sergey, just to make sure we're working toward the same goal here: Ben
Collins-Sussman created this branch for you
http://svn.collab.net/repos/svn/branches/neon-0.24/
I think the idea is that first we -- uh, you -- get Neon 0.24 working
on the branch, then David Waite and you together get cert support
working on the branch (since by itself, the upgrade to Neon 0.24 is
expected to break certificates in Subversion).
Then we fold the branch back into trunk.
I'm aware that neither you nor David Waite have promised that all this
will happen :-), so this mail is really a question: does this plan
sound good to you guys?
If it does, mail me your tigris username and a password of your choice
(plain text or crypted is fine), and I'll set you up with commit
access on that branch.
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Neon 0.24 testing
Posted by "Sergey A. Lipnevich" <se...@optimaltec.com>.
cmpilato@collab.net wrote:
>"Sergey A. Lipnevich" <se...@optimaltec.com> writes:
>
>>hat explains it, thanks! There's a return code specifically defined
>>for this purpose: NE_XML_INVALID==-1 (or SVN_RA_DAV__XML_INVALID or
>>something like that), which in turn is NE_XML_ABORT==-1 in the new
>>Neon interface. With your permission I'll go on and change this 1 to
>>SVN_RA_DAV__XML_INVALID then, alright?
>>
>>
>I'm not sure why we have this extra level of indirection (as an
>intermediate step during this API transition?), but I trust you. Make
>it so.
>
>
Sure, thank you :-)! That's precisely the reason: NE_XML_INVALID became
NE_XML_ABORT in Neon 0.24 without changing the value (-1), and return
value contract has changed for startelm callback (NE_XML_DECLINE is now
0 instead of -2). And there's no validate callback anymore, but that's
another story...
Re: Neon 0.24 testing
Posted by cm...@collab.net.
"Sergey A. Lipnevich" <se...@optimaltec.com> writes:
> > I can't speak for the author of fetch.c, but when I rewrote the
> > handlers for props.c, I was noting this: "If any of the callbacks ever
> > return non-zero, the parse with STOP."
>
> That explains it, thanks! There's a return code specifically defined
> for this purpose: NE_XML_INVALID==-1 (or SVN_RA_DAV__XML_INVALID or
> something like that), which in turn is NE_XML_ABORT==-1 in the new
> Neon interface. With your permission I'll go on and change this 1 to
> SVN_RA_DAV__XML_INVALID then, alright?
I'm not sure why we have this extra level of indirection (as an
intermediate step during this API transition?), but I trust you. Make
it so.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Neon 0.24 testing
Posted by "Sergey A. Lipnevich" <se...@optimaltec.com>.
cmpilato@collab.net wrote:
> "Sergey A. Lipnevich" <se...@optimaltec.com> writes:
>
>
>>Hi All,
>>
>>Could somebody please look at the following errors for basic_tests.py
>>#1? First of all, "old-style" (pre 0.24) callbacks, "startelm" and
>>"endelm" in props.c and fetch.c (I'm talking about libsvn_ra_dav)
>>sometimes return value 1, which is not defined by Neon interface. What
>>is defined is -1 (invalid XML) or -2 (decline element). If I treat
>>return 1 as error, I get test failure:
>
>
> This from ne_xml.h:
>
> /* Push a handler onto the handler stack for the given list of elements.
> * elements must be an array, with the last element .nspace being NULL.
> * Callbacks are called in order:
> * 1. validate_cb
> * 2. startelm_cb
> * 3. endelm_cb
> * (then back to the beginning again).
> * If any of the callbacks ever return non-zero, the parse will STOP.
> * userdata is passed as the first argument to startelm_cb and endelm_cb.
> */
> void ne_xml_push_handler(ne_xml_parser *p,
> const struct ne_xml_elm *elements,
> ne_xml_validate_cb validate_cb,
> ne_xml_startelm_cb startelm_cb,
> ne_xml_endelm_cb endelm_cb,
> void *userdata);
>
> I can't speak for the author of fetch.c, but when I rewrote the
> handlers for props.c, I was noting this: "If any of the callbacks ever
> return non-zero, the parse with STOP."
That explains it, thanks! There's a return code specifically defined for
this purpose: NE_XML_INVALID==-1 (or SVN_RA_DAV__XML_INVALID or
something like that), which in turn is NE_XML_ABORT==-1 in the new Neon
interface. With your permission I'll go on and change this 1 to
SVN_RA_DAV__XML_INVALID then, alright?
Sergey.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Neon 0.24 testing
Posted by cm...@collab.net.
"Sergey A. Lipnevich" <se...@optimaltec.com> writes:
> Hi All,
>
> Could somebody please look at the following errors for basic_tests.py
> #1? First of all, "old-style" (pre 0.24) callbacks, "startelm" and
> "endelm" in props.c and fetch.c (I'm talking about libsvn_ra_dav)
> sometimes return value 1, which is not defined by Neon interface. What
> is defined is -1 (invalid XML) or -2 (decline element). If I treat
> return 1 as error, I get test failure:
This from ne_xml.h:
/* Push a handler onto the handler stack for the given list of elements.
* elements must be an array, with the last element .nspace being NULL.
* Callbacks are called in order:
* 1. validate_cb
* 2. startelm_cb
* 3. endelm_cb
* (then back to the beginning again).
* If any of the callbacks ever return non-zero, the parse will STOP.
* userdata is passed as the first argument to startelm_cb and endelm_cb.
*/
void ne_xml_push_handler(ne_xml_parser *p,
const struct ne_xml_elm *elements,
ne_xml_validate_cb validate_cb,
ne_xml_startelm_cb startelm_cb,
ne_xml_endelm_cb endelm_cb,
void *userdata);
I can't speak for the author of fetch.c, but when I rewrote the
handlers for props.c, I was noting this: "If any of the callbacks ever
return non-zero, the parse with STOP."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org