On Mon, Apr 05, 2004 at 02:27 +0200, C.A.T.Magic wrote:
> I do not like the file:/// access for the reason that each program comes
> with its 'own' svn file:/// access module. one user/tool could access
> it with svn-1.0.0 another can use svn-1.0.1 and one could even use some
> unstable svn -rev xyz build or a build from some buggy compiler
> (maybe just that one optimization flag too much...).
> If all access is channeled through a single svn version (svnserve or
> apache module) you can at last know that you should blame exactly that
> binary&version for doing a corruption.
> but i do prefer file:/// access for local svn -experiments- because of
> its speed and easy (sandbox-) repos setup.
> i'd at least prefer to have a single svn.dll or svn.so and force
> all programs to access the repos through and -only- through that
> 'proofed' module.
Getting only one version of the code to manage the database files is
only half of the problem. If you are accessing a private repository for
experimentation, this is all fine and well. But with the central source
repository shared with several people I am more worried about programs
that fail to catch all possible exceptions or even worse that have
internal memory corruptions (may not yet be fully debugged) and have in
the same process space the buffers for the database.
--
Jens-Uwe Mager <pgp-mailto:F476EBC2>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 5 03:06:08 2004