You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by root <da...@axiom-developer.org> on 2006/10/02 06:28:44 UTC
svn failures
my console log.
svn co https://svn.sourceforge.net/svnroot/magnus/branches/daly magnus
.... checkout out a bunch of files
svn: REPORT request failed on '/svnroot/magnus/!svn/vcc/default'
svr: REPORT of '/svnroot/magnus/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
cd magnus
svn update
.... checkout out a bunch of files
svn: REPORT request failed on '/svnroot/magnus/!svn/vcc/default'
svr: REPORT of '/svnroot/magnus/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
svn update
.... checkout out a bunch of files
svn: REPORT request failed on '/svnroot/magnus/!svn/vcc/default'
svr: REPORT of '/svnroot/magnus/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
svn update
.... checkout out a bunch of files
svn: REPORT request failed on '/svnroot/magnus/!svn/vcc/default'
svr: REPORT of '/svnroot/magnus/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
svn update
.... checkout out a bunch of files
svn: REPORT request failed on '/svnroot/magnus/!svn/vcc/default'
svr: REPORT of '/svnroot/magnus/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
svn update
.... checkout out a bunch of files
svn: REPORT request failed on '/svnroot/magnus/!svn/vcc/default'
svr: REPORT of '/svnroot/magnus/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
svn update
.... checkout out a bunch of files
svn: REPORT request failed on '/svnroot/magnus/!svn/vcc/default'
svr: REPORT of '/svnroot/magnus/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
svn update
.... checkout out a bunch of files
svn: REPORT request failed on '/svnroot/magnus/!svn/vcc/default'
svr: REPORT of '/svnroot/magnus/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
svn update
.... checkout out a bunch of files
svn: REPORT request failed on '/svnroot/magnus/!svn/vcc/default'
svr: REPORT of '/svnroot/magnus/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
svn update
.... checkout out a bunch of files
svn: REPORT request failed on '/svnroot/magnus/!svn/vcc/default'
svr: REPORT of '/svnroot/magnus/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
svn update
.... checkout out a bunch of files
svn: REPORT request failed on '/svnroot/magnus/!svn/vcc/default'
svr: REPORT of '/svnroot/magnus/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
svn update
.... checkout out a bunch of files
svn: REPORT request failed on '/svnroot/magnus/!svn/vcc/default'
svr: REPORT of '/svnroot/magnus/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
svn update
.... checkout out a bunch of files
Update to revision 184
cd ..
(redo all of my changes, adding directory 'version6')
svn add version6
svn commit -m"version 6"
....................................................
.....[snip].....
....................................................
svn: MERGE request failed on '/svnroot/magnus/branches/daly'
svn: MERGE of '/svnroot/magnus/branches/daly': 500 Internal Server Error (https://svn.sourceforge.net)
Fourth failure of this type in 4 days (it's after midnight).
So I wasted another 2 hours. And I get to waste 2 more.
If I only had a problem with subversion on the magnus project
I could figure it's not a big problem.
But it also fails sometimes on the Axiom project.
But that's also hosted on sourceforge so maybe it's just sourceforge.
But I also use subversion for work (not sourceforge) and it
occasionally fails. Oh, and svn cleanup is pointless. It never clears
locks. Never. The only effective solution is to rm -rf, checkout,
redo the work, commit and pray.
Sometimes it fails, sometimes it doesn't. Mostly luck.
Today isn't my lucky day.
Subversion should 'just work'.
But it doesn't.
Tim, 'it should just work', Daly
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [Axiom-developer] svn failures
Posted by Gabriel Dos Reis <gd...@integrable-solutions.net>.
root <da...@axiom-developer.org> writes:
[...]
| Sometimes it fails, sometimes it doesn't. Mostly luck.
| Today isn't my lucky day.
I think you can
(1) classify SF/SVN as broken;
(2) suffer the pain of initial checkout with SVK, and enjoy the rest
seamlessly;
(3) posit there is something between you and SVN.
-- Gaby
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn failures
Posted by Ben Collins-Sussman <su...@google.com>.
On 10/2/06, root <da...@axiom-developer.org> wrote:
> > > svn: REPORT request failed on '/svnroot/magnus/!svn/vcc/default'
> > > svr: REPORT of '/svnroot/magnus/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
> >
> > Something is very messed up with sourceforge's svn server. Report
> > this to sourceforge! It's not normal at all.
>
>
> I fully agree that sourceforge is broken. My gut feel (and this is
> just a guess) is that SVN relies heavily on tmp space in order to
> do 'transactions'. sourceforge probably randomly runs out of tmp space
> depending on how many SVN sessions are running. Since sourceforge would
> not SEE the errors they can validly claim that it isn't their fault.
The error message above looks like a full-out apache crash, not a
simple 'ran out of tmp space'. The sourceforge guys should see a real
crash in their logs.
Yes, when you run 'svn update', a tiny description of your working
copy is sent to the server (what versions of what files you have), and
it sits in a tmpfile. The server then reads that tmpfile and knows
what to send back. The tmpfile is automatically deleted when the
connection closes.
> My issue isn't with the setup of the system but with the design. It
> is my belief that SVN does not properly recover from these failures in
> any convenient way. It should be possible to automatically retry a
> transaction or, if not that, to restart a transaction. Network and
> storage errors are usually temporary but SVN does not recover well at
> all. Often times my work system gets wedged into a state with 'locks'.
> In work we use 'tortoise' as a windows cover and it recommends that we
> run cleanup. (BTW, why have cleanup? Why not just fail to a clean
> state instead?) Cleanup takes a long time and NEVER succeeds. Once a
> transaction fails SVN leaves the world in a broken state and the only
> recovery action available is to redo the work
I admit, I'm not following your train of thought here. I initially
thought you were talking about retrying commit-attempts in the
repository (which we refer to as 'transactions' before the commit
succeeds.) But I think you're talking about the fragility of the
working copy, rather?
The working copy, unlike CVS, is a completely journaled system. If
you 'kill -9' a cvs update, you're likely to get silently corrupted
data. If you do the same to an svn update, the whole process was
journaled, and that's what 'svn cleanup' is for... to execute the
journals and return the working copy to a consistent state.
Obviously, one cannot 'just fail to a clean state', because
interruptions aren't perfectly predictable. That's why journaling is
a great technique. Granted, journals can't always recover things, but
they usually do.
> Claiming I'm an 'outlier' on the usage curve is not solution.
I didn't claim it was a solution to your problem. I'm just saying
that you're falling into the classic trap of "it doesn't work for me,
therefore it must be a fundamentally broken design, and it must be
lousy for everyone else in the world." That's not a rational position
to take. :-)
The only solution I can recommend is to send detailed transcripts of
your errors to a support list and figure out what's going on in your
*particular* setup. Generalization isn't productive. Specific
troubleshooting is.
> Perhaps I'm using SVN in some stupid way and don't know all of the
> special switches. But really, how hard is this? Checkout, change,
> commit. That's all I ever do. It should 'just work'.
Agreed, it should just work. And it does for 99% of people.
I shouldn't be intruding on your discussions, so I'll bow out. Good
luck to you guys! Tim, if you want to discuss theory/design or just
troubleshoot stuff, I invite you to join users@subversion.tigris.org.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn failures
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Oct 2, 2006, at 10:10, root wrote:
> storage errors are usually temporary but SVN does not recover well at
> all. Often times my work system gets wedged into a state with 'locks'.
> In work we use 'tortoise' as a windows cover and it recommends that we
> run cleanup. (BTW, why have cleanup? Why not just fail to a clean
> state instead?) Cleanup takes a long time and NEVER succeeds.
I can only say that automatically cleaning up would defeat the
purpose. The purpose is this: while some Subversion operations run,
they modify your working copy, and they require that they are the
only process modifying the working copy. If you run an "svn update,"
for example, and it takes 10 minutes, and 5 minutes into the process
you start another "svn update" it should fail and say that the
working copy is locked (by the first update process) and to run "svn
cleanup" if you feel the locks should be removed. If Subversion
automatically did this, the first update process would be disturbed.
The advisory to clean up is intended for the cases where the above
hypothetical first update process has crashed and you therefore need
to remove the working copy locks manually.
In the case you are experiencing, "svn cleanup" is presumably not
relevant, despite what Subversion suggests, which is why running it
has no discernible effect.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn failures
Posted by root <da...@axiom-developer.org>.
> > svn: REPORT request failed on '/svnroot/magnus/!svn/vcc/default'
> > svr: REPORT of '/svnroot/magnus/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
>
> Something is very messed up with sourceforge's svn server. Report
> this to sourceforge! It's not normal at all.
I fully agree that sourceforge is broken. My gut feel (and this is
just a guess) is that SVN relies heavily on tmp space in order to
do 'transactions'. sourceforge probably randomly runs out of tmp space
depending on how many SVN sessions are running. Since sourceforge would
not SEE the errors they can validly claim that it isn't their fault.
My issue isn't with the setup of the system but with the design. It
is my belief that SVN does not properly recover from these failures in
any convenient way. It should be possible to automatically retry a
transaction or, if not that, to restart a transaction. Network and
storage errors are usually temporary but SVN does not recover well at
all. Often times my work system gets wedged into a state with 'locks'.
In work we use 'tortoise' as a windows cover and it recommends that we
run cleanup. (BTW, why have cleanup? Why not just fail to a clean
state instead?) Cleanup takes a long time and NEVER succeeds. Once a
transaction fails SVN leaves the world in a broken state and the only
recovery action available is to redo the work.
Clearly SVN 'works' since I can do a checkout followed by 10 updates
and I get all my code back. It 'works' in theory.
A code archive is just a way to store and recover work.
It should be as robust as a copy operation and just as easy to use.
Imagine if copy 'locked' your source directory so you couldn't
restart the copy. And the cleanup command couldn't fix it?
Would that be a reasonable design for the 'cp' command?
Claiming I'm an 'outlier' on the usage curve is not solution.
Perhaps I'm using SVN in some stupid way and don't know all of the
special switches. But really, how hard is this? Checkout, change,
commit. That's all I ever do. It should 'just work'.
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn failures
Posted by Ben Collins-Sussman <su...@google.com>.
On 10/2/06, root <da...@axiom-developer.org> wrote:
> svn: REPORT request failed on '/svnroot/magnus/!svn/vcc/default'
> svr: REPORT of '/svnroot/magnus/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
Something is very messed up with sourceforge's svn server. Report
this to sourceforge! It's not normal at all.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org