[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [patch] Making Ruby Windows bindings sqlite aware

From: Joe Swatosh <joe.swatosh_at_gmail.com>
Date: 2007-03-24 03:26:33 CET

Hi Dan

On 3/23/07, Daniel Rall <dlr@collab.net> wrote:
> Joe, how does this patch play with your "add copying of bdb and sqlite
> dlls to win-tests.py" patch?
> - Dan


Poorly named first patch:
[patch] Make Ruby Windows bindings tests sqlite3 aware.

Actually has two separate issues chomping the get-make.opt lines and
adding sqlite3 to the list of binaries that must be copied to a
"svnserve" directory. Controlling svnserve from Ruby on Windows is a
nightmare without fork, to make it easier, I suggested that we install
svnserve as a windows service. kou decided that worked, but wanted to
control the svnserver that was started. Since we can't control the
path for the process that the service starts in, we copy the relevant
binaries to a know place and install and run it from there. All this
patch does is add sqlite3.dll to the list of binaries to copy. This
effects only the running of the Ruby bindings tests (and only the
client tests at that).

Second patch:
[patch] add copying of bdb and sqlite dlls to win-tests.py

This patch effects the running of the Subversion tests on windows.
I'm not sure of the policy that governs whether or not a binary is
copied by this script before running the tests. Since it is more
convenient for me and seems more consistent to me, I patched to copy
all the dependencies (that I'm aware of) instead of just some.

Third patch:
[patch] Making Ruby Windows bindings sqlite aware (no period this
time, what was I thinking?)

This is most similar to the second patch except that it is only for
the process that is running the ruby bindings tests. It adds the bdb
and sqlite directories to the path of the process that is running the
tests. (Similar in spirit, not in approach to the second patch)

While I was typing, I see that kou applied a version of this patch,
but I hope this provides a little explanation of what I was trying to
do today.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 24 03:26:48 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.