You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Robin Becker <ro...@reportlab.com> on 2004/06/25 11:17:17 UTC
apache locks up db?
A colleague tried to incorporate changes from one database into another using
commands of the form
svn merge -r 14269:HEAD https://localhost/svn/private/presales/trunk presales
which was carried out in trunk checked out from
https://localhost/svn/private_new/trunk
the repository paths of the changed and to be changed files are obviously very
different
ie https://localhost/svn/private/presales/trunk vs
https://localhost/svn/private_new/trunk/presales, but he claimed that this would
work. The above commands all appeared to work and did modify the working dir,
but when we tried to commit this change it failed with strange error messages,
but worse after retrying we found we had locked the database out even to
recover. Restarting apache worked and allowed the svnadmin recover to work.
However, this makes me worried that apache may not be the safest way to access
svn. My boss wants to use https/http as he feels that will allow clients with
firewalls access etc etc. Do other svn'ers have experience on this sort of
problem? Do the svn modules manage svn databases as long running processes?
--
Robin Becker
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: apache locks up db?
Posted by Ben Collins-Sussman <su...@collab.net>.
On Fri, 2004-06-25 at 12:43, Robin Becker wrote:
> We then had various problems and found that something was wrong with the source
> of the merge; we couldn't ls its root folder, but subfolders were ok. I have a
> feeling that was the source of the problem. Attempts to fix up that repository
> failed ie svnadmin recover hung. We managed to get svnadmin recover to work by
> restarting apache. Clearly someone had locked something. I assume somehow using
> the commands above we managed to create a loop in the root folder or something.
Sure, you're not supposed to run 'svnadmin recover' unless you have
exclusive access to the repository. That means shutting off apache,
svnserve, and so on.
Really, we'd need to see a transcript of what commit commands caused the
lockup. To begin with, though, I suggest you read this FAQ and the book
section it mentions. The most common cause of database 'lockups' are
permissions problems:
http://subversion.tigris.org/project_faq.html#permissions
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: apache locks up db?
Posted by Robin Becker <ro...@reportlab.com>.
Ben Collins-Sussman wrote:
.....
>
> This first problem is user error: 'svn merge' cannot merge changes from
> one repository to another. It often creates 'schedule-add' items in the
> working copy that remember where they came from ("add with history")...
> and if they come from a foreign repository, the commit will fail.
thanks for the explanation. I didn't believe it would work, but Mike insisted
and it got us into a state of panic as we were not sure what the problem was and
this was 'big conversion from cvs day' :)
>>but worse after retrying we found we had locked the database out even to
>>recover. Restarting apache worked and allowed the svnadmin recover to work.
>
>
> This sounds like a very different problem. In theory, there should be
> no way for an svn client to cause an apache process to crash or
> disconnect from the database uncleanly. In practice, this seems to be
> pretty true as well. If you've found a way to make that happen, we'd
> love to know how. But that involves getting a lot more detail from you
> and doing some research.
>
I'm quite prepared to assist.
The main problem was doing the above and then finding that the destination
repository had 'gone away' ie the commit failed.
We then had various problems and found that something was wrong with the source
of the merge; we couldn't ls its root folder, but subfolders were ok. I have a
feeling that was the source of the problem. Attempts to fix up that repository
failed ie svnadmin recover hung. We managed to get svnadmin recover to work by
restarting apache. Clearly someone had locked something. I assume somehow using
the commands above we managed to create a loop in the root folder or something.
Please let me know what I can do in the way of research? Unfortunately these are
big repositories bz2 of the hotcopy is 380Mb. I have a snapshot of the source
and can reasonably create another destination.
>
>>However, this makes me worried that apache may not be the safest way to access
>>svn. My boss wants to use https/http as he feels that will allow clients with
>>firewalls access etc etc. Do other svn'ers have experience on this sort of
>>problem? Do the svn modules manage svn databases as long running processes?
>
>
> The svn client opens a single long-running TCP/IP connection to an
> apache process, and then does many HTTP request/repsonses over that
> connection. The apache process keeps the database open throughout the
> connection.
Again thanks for the info.
--
Robin Becker
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: apache locks up db?
Posted by Ben Collins-Sussman <su...@collab.net>.
On Fri, 2004-06-25 at 06:17, Robin Becker wrote:
> A colleague tried to incorporate changes from one database into another using
> commands of the form
>
> svn merge -r 14269:HEAD https://localhost/svn/private/presales/trunk presales
>
>
> which was carried out in trunk checked out from
>
> https://localhost/svn/private_new/trunk
>
> the repository paths of the changed and to be changed files are obviously very
> different
>
> ie https://localhost/svn/private/presales/trunk vs
> https://localhost/svn/private_new/trunk/presales, but he claimed that this would
> work. The above commands all appeared to work and did modify the working dir,
> but when we tried to commit this change it failed with strange error messages,
You're describing two separate problems. Let's not mix them.
This first problem is user error: 'svn merge' cannot merge changes from
one repository to another. It often creates 'schedule-add' items in the
working copy that remember where they came from ("add with history")...
and if they come from a foreign repository, the commit will fail.
> but worse after retrying we found we had locked the database out even to
> recover. Restarting apache worked and allowed the svnadmin recover to work.
This sounds like a very different problem. In theory, there should be
no way for an svn client to cause an apache process to crash or
disconnect from the database uncleanly. In practice, this seems to be
pretty true as well. If you've found a way to make that happen, we'd
love to know how. But that involves getting a lot more detail from you
and doing some research.
> However, this makes me worried that apache may not be the safest way to access
> svn. My boss wants to use https/http as he feels that will allow clients with
> firewalls access etc etc. Do other svn'ers have experience on this sort of
> problem? Do the svn modules manage svn databases as long running processes?
The svn client opens a single long-running TCP/IP connection to an
apache process, and then does many HTTP request/repsonses over that
connection. The apache process keeps the database open throughout the
connection.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org