On 3/28/07, David Parish <dparish@gmail.com> wrote:
> I had this problem with Apache as well. I fixed it by changing the
> following in httpd.conf (It was awhile ago so I may have forgotten
> something)
>
> KeepAlive on
> TimeOut 600
>
> -Dave
>
>
>
> On 3/28/07, Larry Martell <larry.martell@gmail.com> wrote:
> > On 3/25/07, Troy Curtis Jr <troycurtisjr@gmail.com> wrote:
> > > Hi all,
> > > At work several users have had their commit exit with the "Connection
> > > Closed Unexpectedly" error message. Upon further investigation it
> > > turns out that the commit makes it into the repository correctly, but
> > > the working copy is left in such a screwed up state that they have to
> > > do a fresh checkout to recover. (The working copy shows that the
> > > commit failed and so does not update the version information for the
> > > files commited, a 'svn up' causes conflicts galore). It also appears
> > > that one particularly large text file (actually ridiculously large),
> > > along with a generally large commit is common among the three case we
> > > encountered (many other revs have gone through just fine).
> > >
> > > Our repository is fairly large at ~2GB and 60k+ revisions.
> > > Furthermore, our code tree is very complex with many many directories
> > > at variable depths. We are using Subversion 1.4.1. The repository is
> > > BDB back-end served off Subversion's own 'svnserve' server. I thought
> > > I remembered something about the head revision re-write aspect of BDB
> > > repos could cause timeouts on large commits but I couldn't find
> > > anything on it.
> > >
> > > Does anyone have any ideas? Would a transition to an Apache served
> > > repository help?
> >
> > I have seen this on repositories located on network drives accessed with
> > the file:/// method. I have never seen this on repos located on a server
> > accessed with https://. So I would say the answer to your question is yes.
> >
> > HTH,
> > -larry
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
PERFECT!! That is exactly the configurability that I thought would be
in place when using apache. It makes me feel much more confident now
in moving my users to the http method. I wanted to do it anyway
because of the ability to browse the repo from a web browser, and have
links off our internal wiki to the actual repository, etc. Now I can
be confident in waiting for the switch before investigating this issue
further.
Troy
--
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 29 05:33:53 2007