Here's a suggested approach:
Run svnserve on the same machine as the svn client.
Run Ethereal to trace the packets on the loopback interface. See the
HACKING document for hints/instructions on how to do that or the
Ethereal documentation.
Perform various operations (that your proxy should track) using the svn
client.
For each operation, save the trace.
Compare the traces against the protocol document
in the svn repository to build requirements for your proxy.
Use those traces to implement your proxy.
This strategy is likely to reduce the difficulty in setting up a network
sniffer on multiple machines.
Your emails ask for help with a variety of things. It is difficult to
respond to all of them, so it would make it easier to respond if one
email focuses on a specific area. Often, following this focusing
procedure will in turn help you to do the research yourself using the
detailed information in the mailing list archives. Specifically, in an
email, list the operation the client is doing, as e.g.:
svn ls svn://localhost/repos/foo-repos/trunk/bar-file
Then, if svnserve or svn doesn't behave according to your understanding
of the svnserve protocol for a specific svn operation, send an email
describing your understanding, the operation, what actually happened,
and, if possible, your conjecture about why the client or server behaved
the way they did. I think you will probably get a more useful response.
HTH
Sameer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 10 09:06:27 2005