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

Re: file: Access vs. Database stability

From: C.A.T.Magic <c.a.t.magic_at_gmx.at>
Date: 2004-04-05 02:27:58 CEST

Jens-Uwe Mager wrote:

>>From running a subversion server for quite a while (about over a year
> now) I get the feeling that for stability of the main server we
> absolutely have to ban all access via file urls and other non-http
> access methods. this in particular appears to affect viewcvs and similar
> which appears to have wedged our repository several times the last few
> days alone.
> This appears to contradict the recommendation of the developers to use
> the direct svn API for utilities like viewcvs. I am getting the feeling
> that this recommendation is a reciepe for disaster, as you never get a
> stable repository as long as you allow develpment of utilities using the
> direct access methods. What do the others think about this conflict?

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.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 5 02:28:00 2004

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.