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
Received on Fri Jun 25 17:54:24 2004