You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Summers <da...@summersoft.fay.ar.us> on 2003/10/07 22:08:54 UTC
Problems with 0.31.0
I was rushing to get subversion-0.31.0-7347 RPM build to make sure it
would work with all the last minute changes and it built fine (after
upgrading to neon-0.24.3).
However, now when I try to update the subversion working copy I get:
[david@amd subversion]$ svn update
svn: RA layer request failed
svn: PROPFIND request failed on '/repos/svn/branches/release-0.31.0'
svn: The PROPFIND request returned invalid XML in the response: Unknown
error. (/repos/svn/branches/release-0.31.0)
I erased the .subversion directory and re-tried with the same error.
Have I missed something or am I doing something silly or ...... ?????????
- David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems with 0.31.0
Posted by "C. Michael Pilato" <cm...@collab.net>.
"C. Michael Pilato" <cm...@collab.net> writes:
> "C. Michael Pilato" <cm...@collab.net> writes:
>
> > It would appear that in neon 0.24.3, the error is never left NULL, but
> > is instead initialized to "Unknown error". There must, then, be some
> > other way to check for an errorful state. Now... where is that
> > booger...
>
> A-ha! We should be calling ne_xml_valid(), and only if the XML was
> invalid should we try to fetch the error. Testing a patch now.
Well, the patch works ... kinda. Errors are handled a little
differently now it seems, and that's causing some tests to fail. I
have a plan of attack -- executing now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems with 0.31.0
Posted by "C. Michael Pilato" <cm...@collab.net>.
Joe Orton <jo...@redhat.com> writes:
> If I understand this correctly: the issue is that ra_dav needs to be
> able to distinguish between an error from the XML parser itself and an
> error which occurs when ra_dav's SAX callbacks return a <0 value.
>
> There's never been a way to do this in the neon API, though it's a
> definitely a reasonable feature to have.
Well, actually, there *was* a way to do it (because we were doing it),
though it may not have been a documented API feature. We used to
never call ne_xml_valid(), and always check ne_xml_get_error(). If
that returned NULL or empty string, we knew (for loose definitions of
"knew") that no XML parser error had happened. We can't do that
anymore because ne_xml_get_error() always returns some non-empty
string.
We could continue to do this if Neon promised to leave its own
p->error member NULL unless ne_xml_set_error() was called, or unless
some real error occured.
Heh.
I just realized something.[1]
> I'd recommend limiting SVN to using 0.24.[0-2] and working out how
> to add this to neon rather than performing major surgery on ra_dav
> (I expect the latter would be more work than the former).
I have no problems with this. I was able to get the tests to pass
over ra_dav with not too many mods, but overall I don't have 100% that
those mods encompass the spirit of what we want to accomplish. The
system is complicated because Neon has it own errors that happen,
there are true XML parser errors (malformed, etc.), there are errors
that occur when the XML callbacks go off to do other things
(svn_error_t's), and there are errors marshaled through the XML
responses themselves from mod_dav_svn.
Yick.
[1] While typing the above, I realize that I could fix this problem
in one line of code. I simply needed to call:
ne_xml_set_error(success_parser, "");
before dispatching the request. This overrides the "Unknown error"
initialization that was added in 0.24.3, and should work just fine
with 0.24.2, also. It's a bit hacky, but it will buy us some time
(letting folks upgrade to 0.24.3, if only so it builds in Windows)
while we solve the larger error handling issue.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems with 0.31.0
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Oct 08, 2003 at 01:41:33AM -0500, Mike Pilato wrote:
> "C. Michael Pilato" <cm...@collab.net> writes:
>
> > "C. Michael Pilato" <cm...@collab.net> writes:
> >
> > > It would appear that in neon 0.24.3, the error is never left NULL, but
> > > is instead initialized to "Unknown error". There must, then, be some
> > > other way to check for an errorful state. Now... where is that
> > > booger...
> >
> > A-ha! We should be calling ne_xml_valid(), and only if the XML was
> > invalid should we try to fetch the error. Testing a patch now.
>
> Okay, well, this turned out to be trickier than I thought.
If I understand this correctly: the issue is that ra_dav needs to be
able to distinguish between an error from the XML parser itself and an
error which occurs when ra_dav's SAX callbacks return a <0 value.
There's never been a way to do this in the neon API, though it's a
definitely a reasonable feature to have. I'd recommend limiting SVN to
using 0.24.[0-2] and working out how to add this to neon rather than
performing major surgery on ra_dav (I expect the latter would be more
work than the former).
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems with 0.31.0
Posted by "C. Michael Pilato" <cm...@collab.net>.
"C. Michael Pilato" <cm...@collab.net> writes:
> "C. Michael Pilato" <cm...@collab.net> writes:
>
> > It would appear that in neon 0.24.3, the error is never left NULL, but
> > is instead initialized to "Unknown error". There must, then, be some
> > other way to check for an errorful state. Now... where is that
> > booger...
>
> A-ha! We should be calling ne_xml_valid(), and only if the XML was
> invalid should we try to fetch the error. Testing a patch now.
Okay, well, this turned out to be trickier than I thought.
Our XML parser callbacks tend to, on errorful conditions, set a
descriptive svn_error_t in their batons and then return XML_INVALID.
Now, in Neon 0.24.2, it seems that just returning XML_INVALID causes
neon to abort the parsing of the request response, but it wouldn't
touch its own internal error message field (accessed via
ne_xml_get_error()), choosing to leave it NULL as initialized. This
meant that svn_ra_dav__parsed_request (which just checked
ne_xml_get_error()) would *not* return an error, callers of that
function would not immediately return errorfully, and they would then
check their own baton's for errors (which they would of course find
and return). Wah-lah! You get a descriptive error message.
In neon 0.24.3, the neon error string is now never NULL or empty, so
we can't really use that as our "did this parse fail" check. So we
have to use ne_xml_valid() to see if the parse failed, and if it did,
we return the neon error. Of course, most of the times the XML isn't
valid is because some Subversion error occurred and the callbacks
returned XML_INVALID. This means that neon knows the XML was invalid,
but still has its error message set to "Unknown error" (it only
changes its own error messsage when some internal error occurs).
This, in turn, means that svn_ra_dav__parsed_request() will return a
parser error that has virtually no useful information (I mean,
"Unknown error" gets to be less than unique across the many places
errors could happen), which callers will immediately return instead of
noticing that some really useful Subversion error also exists in their
baton. Boo-hoo! You get a useless error message.
Three solutions:
(1) Change the XML parser callbacks (start_element et al) to,
instead of just returning XML_INVALID, also call
ne_xml_set_error(). Of course, this neon function takes a
string, which means we'd have to have code that flatters out
the messages in the svn_error_t * chain to a single 'const char
*'. Oh, but neon doesn't tell you that it will truncate the
error message you transmit through this function to 2048
characters. :-(
(2) Make svn_ra_dav__parsed_request() treat the neon error with the
string "Unknown error" the same way we currently treat NULL or
the empty string. This just seems wrong.
(3) Make callers of svn_ra_dav__parsed_request() first return their
baton's svn_error_t first, then fallback to the error returned
from svn_ra_dav__parsed_request().
For now, I'm going with solution 3.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems with 0.31.0
Posted by "C. Michael Pilato" <cm...@collab.net>.
"C. Michael Pilato" <cm...@collab.net> writes:
> It would appear that in neon 0.24.3, the error is never left NULL, but
> is instead initialized to "Unknown error". There must, then, be some
> other way to check for an errorful state. Now... where is that
> booger...
A-ha! We should be calling ne_xml_valid(), and only if the XML was
invalid should we try to fetch the error. Testing a patch now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems with 0.31.0
Posted by "C. Michael Pilato" <cm...@collab.net>.
"C. Michael Pilato" <cm...@collab.net> writes:
> Diffs between neon-0.24.2 and neon-0.24.3 which include the string
> "Unknown error.":
>
> diff -ru neon-0.24.2/src/ne_xml.c neon-0.24.3/src/ne_xml.c
> --- neon-0.24.2/src/ne_xml.c 2003-05-10 11:05:59.000000000 -0500
> +++ neon-0.24.3/src/ne_xml.c 2003-09-25 14:05:58.000000000 -0500
> @@ -403,6 +403,7 @@
> p->current = p->root = ne_calloc(sizeof *p->root);
> p->root->default_ns = "";
> p->root->state = 0;
> + strcpy(p->error, _("Unknown error"));
> #ifdef HAVE_EXPAT
> p->parser = XML_ParserCreate(NULL);
> if (p->parser == NULL) {
> diff -ru neon-0.24.2/test/xml.c neon-0.24.3/test/xml.c
> --- neon-0.24.2/test/xml.c 2003-05-10 11:13:39.000000000 -0500
> +++ neon-0.24.3/test/xml.c 2003-09-25 14:05:58.000000000 -0500
> @@ -424,6 +438,9 @@
> ne_xml_parser *p = ne_xml_create();
> const char *err;
>
> + ONV(strcmp(ne_xml_get_error(p), "Unknown error") != 0,
> + ("initial error string unspecified"));
> +
> ne_xml_set_error(p, "Fish food");
> err = ne_xml_get_error(p);
>
> Joe, can you help us out here? Did we miss something important?
Hmm... we do this after all custom neon requests (from
libsvn_ra_dav/util.c:596):
/* was there an XML parse error somewhere? */
msg = ne_xml_get_error(success_parser);
if (msg != NULL && *msg != '\0')
{
err = svn_error_createf(SVN_ERR_RA_DAV_REQUEST_FAILED, NULL,
"The %s request returned invalid XML "
"in the response: %s. (%s)",
method, msg, url);
goto error;
}
It would appear that in neon 0.24.3, the error is never left NULL, but
is instead initialized to "Unknown error". There must, then, be some
other way to check for an errorful state. Now... where is that
booger...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems with 0.31.0
Posted by "C. Michael Pilato" <cm...@collab.net>.
David Summers <da...@summersoft.fay.ar.us> writes:
> I was rushing to get subversion-0.31.0-7347 RPM build to make sure it
> would work with all the last minute changes and it built fine (after
> upgrading to neon-0.24.3).
>
> However, now when I try to update the subversion working copy I get:
>
> [david@amd subversion]$ svn update
> svn: RA layer request failed
> svn: PROPFIND request failed on '/repos/svn/branches/release-0.31.0'
> svn: The PROPFIND request returned invalid XML in the response:
> Unknown error. (/repos/svn/branches/release-0.31.0)
>
> I erased the .subversion directory and re-tried with the same error.
>
> Have I missed something or am I doing something silly or ...... ?????????
Diffs between neon-0.24.2 and neon-0.24.3 which include the string
"Unknown error.":
diff -ru neon-0.24.2/src/ne_xml.c neon-0.24.3/src/ne_xml.c
--- neon-0.24.2/src/ne_xml.c 2003-05-10 11:05:59.000000000 -0500
+++ neon-0.24.3/src/ne_xml.c 2003-09-25 14:05:58.000000000 -0500
@@ -403,6 +403,7 @@
p->current = p->root = ne_calloc(sizeof *p->root);
p->root->default_ns = "";
p->root->state = 0;
+ strcpy(p->error, _("Unknown error"));
#ifdef HAVE_EXPAT
p->parser = XML_ParserCreate(NULL);
if (p->parser == NULL) {
diff -ru neon-0.24.2/test/xml.c neon-0.24.3/test/xml.c
--- neon-0.24.2/test/xml.c 2003-05-10 11:13:39.000000000 -0500
+++ neon-0.24.3/test/xml.c 2003-09-25 14:05:58.000000000 -0500
@@ -424,6 +438,9 @@
ne_xml_parser *p = ne_xml_create();
const char *err;
+ ONV(strcmp(ne_xml_get_error(p), "Unknown error") != 0,
+ ("initial error string unspecified"));
+
ne_xml_set_error(p, "Fish food");
err = ne_xml_get_error(p);
Joe, can you help us out here? Did we miss something important?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems with 0.31.0
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
David Summers wrote:
> On Tue, 7 Oct 2003 pll@lanminds.com wrote:
>
>
>>In a message dated: Tue, 07 Oct 2003 17:08:54 CDT
>>David Summers said:
>>
>>
>>>I was rushing to get subversion-0.31.0-7347 RPM build to make sure it
>>>would work with all the last minute changes and it built fine (after
>>>upgrading to neon-0.24.3).
>>>
>>>However, now when I try to update the subversion working copy I get:
>>>
>>>[david@amd subversion]$ svn update
>>>svn: RA layer request failed
>>>svn: PROPFIND request failed on '/repos/svn/branches/release-0.31.0'
>>>svn: The PROPFIND request returned invalid XML in the response: Unknown
>>>error. (/repos/svn/branches/release-0.31.0)
>>>
>>>I erased the .subversion directory and re-tried with the same error.
>>>
>>>Have I missed something or am I doing something silly or ...... ?????????
>>
>>can you do an:
>>
>> svn ls -r7345 http://svn.collab.net/repos/svn/branches/release-0.31.0
>>
>>?
>
>
> Nope, I get the same error.
>
>
>
>>It might just be congestion on that server. I find that every now
>>and then just repeating the command usually works.
>>
>>Btw, I'm using r7348 to create the tar-ball.
>
>
> Ok, I'll back down to 0.30 and use it to get 7348 and try that, however I
> really don't think that's the problem because in the mean-time, I ran the
> regression tests and a whole bunch failed on RA_DAV:
Are you absolutely positive you're running the right version of
mod_dav_svn? When testing the release we had failures sort of like this
and it turned out to be an old mod_dav_svn being run. Check the logs
when the server starts up and verify it's the version it should be.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems with 0.31.0
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
David Summers wrote:
> I hadn't run them before a while ago because I was just checking that the
> new neon-0.24.3 and changes in subversion would compile.
You also might want to try with neon 0.24.2, just in case.
So far in #svn we've seen 3 people (you, dj heap, and paul lussier) all
having trouble with the new neon, so it's quite possible that's what's
wrong. Of course it's also possible something else, but you might want
to check just in case.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems with 0.31.0
Posted by su...@collab.net.
> Ok, I'll back down to 0.30 and use it to get 7348 and try that, however
> I really don't think that's the problem because in the mean-time, I
> ran the regression tests and a whole bunch failed on RA_DAV:
>
> Running all tests in basic_tests.py...FAILURE
Stop and restart apache. Now look at apache's error_log. Is it running
mod_dav_svn 0.31?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems with 0.31.0
Posted by "D.J. Heap" <dj...@shadyvale.net>.
And with neon 0.24.2 tests are passing again.
D.J. Heap wrote:
> Here's what I get on Windows with neon 0.24.3 over DAV (going back to
> 0.24.2 and retrying now):
>
> START: basic_tests.py
> CMD: svnadmin.exe "create" "local_tmp\repos" "--bdb-txn-nosync" <TIME =
> 2.464000>
> CMD: svn.exe "import" "--username" "jrandom" "--password" "rayjandom"
> "-m" "Log message for revision 1." "local_tmp\greekfiles"
> "http://localhost/local_tmp/repos" "--config-dir"
> "C:\Temp\junk\subversion\tests\clients\cmdline\local_tmp\config" <TIME =
> 0.270000>
> svn: RA layer request failed
> svn: PROPFIND request failed on '/local_tmp/repos'
> svn: The PROPFIND request returned invalid XML in the response: Unknown
> error. (/local_tmp/repos)
> Errors during initial 'svn import':
> ACTUAL STDERR:
> svn: RA layer request failed
> svn: PROPFIND request failed on '/local_tmp/repos'
> svn: The PROPFIND request returned invalid XML in the response: Unknown
> error. (/local_tmp/repos)
> EXCEPTION: SystemExit(1), skipping cleanup
> FAIL: basic_tests.py 1: basic checkout of a wc
> END: basic_tests.py
>
>
> DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems with 0.31.0
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Tue, 7 Oct 2003, D.J. Heap wrote:
> Here's what I get on Windows with neon 0.24.3 over DAV (going back to
> 0.24.2 and retrying now):
>
> START: basic_tests.py
> CMD: svnadmin.exe "create" "local_tmp\repos" "--bdb-txn-nosync" <TIME =
> 2.464000>
> CMD: svn.exe "import" "--username" "jrandom" "--password" "rayjandom"
> "-m" "Log message for revision 1." "local_tmp\greekfiles"
> "http://localhost/local_tmp/repos" "--config-dir"
> "C:\Temp\junk\subversion\tests\clients\cmdline\local_tmp\config" <TIME =
> 0.270000>
> svn: RA layer request failed
> svn: PROPFIND request failed on '/local_tmp/repos'
> svn: The PROPFIND request returned invalid XML in the response: Unknown
> error. (/local_tmp/repos)
> Errors during initial 'svn import':
That's basically what I was getting on RedHat 9.
I downgraded to neon-0.24.2 and now the error has gone away.
I'm running through the regression tests now but they take a while.....
- David
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems with 0.31.0
Posted by "D.J. Heap" <dj...@shadyvale.net>.
Here's what I get on Windows with neon 0.24.3 over DAV (going back to
0.24.2 and retrying now):
START: basic_tests.py
CMD: svnadmin.exe "create" "local_tmp\repos" "--bdb-txn-nosync" <TIME =
2.464000>
CMD: svn.exe "import" "--username" "jrandom" "--password" "rayjandom"
"-m" "Log message for revision 1." "local_tmp\greekfiles"
"http://localhost/local_tmp/repos" "--config-dir"
"C:\Temp\junk\subversion\tests\clients\cmdline\local_tmp\config" <TIME =
0.270000>
svn: RA layer request failed
svn: PROPFIND request failed on '/local_tmp/repos'
svn: The PROPFIND request returned invalid XML in the response: Unknown
error. (/local_tmp/repos)
Errors during initial 'svn import':
ACTUAL STDERR:
svn: RA layer request failed
svn: PROPFIND request failed on '/local_tmp/repos'
svn: The PROPFIND request returned invalid XML in the response: Unknown
error. (/local_tmp/repos)
EXCEPTION: SystemExit(1), skipping cleanup
FAIL: basic_tests.py 1: basic checkout of a wc
END: basic_tests.py
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems with 0.31.0
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Tue, 7 Oct 2003 pll@lanminds.com wrote:
> In a message dated: Tue, 07 Oct 2003 17:08:54 CDT
> David Summers said:
>
> >I was rushing to get subversion-0.31.0-7347 RPM build to make sure it
> >would work with all the last minute changes and it built fine (after
> >upgrading to neon-0.24.3).
> >
> >However, now when I try to update the subversion working copy I get:
> >
> >[david@amd subversion]$ svn update
> >svn: RA layer request failed
> >svn: PROPFIND request failed on '/repos/svn/branches/release-0.31.0'
> >svn: The PROPFIND request returned invalid XML in the response: Unknown
> >error. (/repos/svn/branches/release-0.31.0)
> >
> >I erased the .subversion directory and re-tried with the same error.
> >
> >Have I missed something or am I doing something silly or ...... ?????????
>
> can you do an:
>
> svn ls -r7345 http://svn.collab.net/repos/svn/branches/release-0.31.0
>
> ?
Nope, I get the same error.
> It might just be congestion on that server. I find that every now
> and then just repeating the command usually works.
>
> Btw, I'm using r7348 to create the tar-ball.
Ok, I'll back down to 0.30 and use it to get 7348 and try that, however I
really don't think that's the problem because in the mean-time, I ran the
regression tests and a whole bunch failed on RA_DAV:
Running all tests in basic_tests.py...FAILURE
Running all tests in commit_tests.py...FAILURE
Running all tests in update_tests.py...FAILURE
Running all tests in switch_tests.py...FAILURE
Running all tests in prop_tests.py...FAILURE
Running all tests in schedule_tests.py...FAILURE
Running all tests in log_tests.py...FAILURE
Running all tests in copy_tests.py...FAILURE
Running all tests in diff_tests.py...FAILURE
Running all tests in export_tests.py...FAILURE
Running all tests in externals_tests.py...FAILURE
Running all tests in merge_tests.py...FAILURE
Running all tests in stat_tests.py...FAILURE
Running all tests in trans_tests.py...FAILURE
Running all tests in autoprop_tests.py...FAILURE
Running all tests in svnadmin_tests.py...FAILURE
Running all tests in svnlook_tests.py...FAILURE
Running all tests in svnversion_tests.py...FAILURE
At least one test FAILED, checking
/home/david/rpms/build/subversion-0.31.0/tests.log
FAIL: basic_tests.py 1: basic checkout of a wc
FAIL: commit_tests.py 1: commit one file
FAIL: update_tests.py 1: update a locally-modified binary file
FAIL: switch_tests.py 1: test some basic switching operations
FAIL: prop_tests.py 1: write/read props in wc only (ps, pl, pdel)
FAIL: schedule_tests.py 1: schedule: add some files
FAIL: log_tests.py 1: 'svn log', no args, top of wc
FAIL: copy_tests.py 1: basic copy and move commands -- on files only
FAIL: diff_tests.py 1: update a file
FAIL: export_tests.py 1: export an empty directory
FAIL: externals_tests.py 1: test checkouts with externals
FAIL: merge_tests.py 1: performing a merge, with mixed results
FAIL: stat_tests.py 1: status on unversioned file in current directory
FAIL: trans_tests.py 1: commit new files with keywords active from birth
FAIL: autoprop_tests.py 1: add: config=no, commandline=none
FAIL: svnadmin_tests.py 1: 'svnadmin dump' on copied directory
FAIL: svnlook_tests.py 1: test 'svnlook youngest' subcommand
FAIL: svnversion_tests.py 1: test 'svnversion' on wc and other dirs
make[1]: *** [check] Error 1
make[1]: Leaving directory `/home/david/rpms/build/subversion-0.31.0'
error: Bad exit status from /home/david/rpms/tmp/rpm-tmp.70779 (%build)
I hadn't run them before a while ago because I was just checking that the
new neon-0.24.3 and changes in subversion would compile.
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems with 0.31.0
Posted by pl...@lanminds.com.
In a message dated: Tue, 07 Oct 2003 17:08:54 CDT
David Summers said:
>I was rushing to get subversion-0.31.0-7347 RPM build to make sure it
>would work with all the last minute changes and it built fine (after
>upgrading to neon-0.24.3).
>
>However, now when I try to update the subversion working copy I get:
>
>[david@amd subversion]$ svn update
>svn: RA layer request failed
>svn: PROPFIND request failed on '/repos/svn/branches/release-0.31.0'
>svn: The PROPFIND request returned invalid XML in the response: Unknown
>error. (/repos/svn/branches/release-0.31.0)
>
>I erased the .subversion directory and re-tried with the same error.
>
>Have I missed something or am I doing something silly or ...... ?????????
can you do an:
svn ls -r7345 http://svn.collab.net/repos/svn/branches/release-0.31.0
?
It might just be congestion on that server. I find that every now
and then just repeating the command usually works.
Btw, I'm using r7348 to create the tar-ball.
--
Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org