Whilst trying to reproduce the problem in issue #1862, I noticed that 
svnserve on Windows still terminates after an error (I'm assuming the 
same would happen on Linux in threaded mode). This time the repro was as 
follows (using cygwin's bash, obviously):
    $ svnadmin create repo-template
    $ vi repo-template/conf/svnserve.conf
    (set anon-access to write)
    $ cp -R repo-template repo
    $ svnserve -d -r repo &
    [repeat several times...
    $ svn co svn://localhost wc1
    Checked out revision 0.
    $ svn co svn://localhost wc2
    Checked out revision 0.
    $ cd wc1
    $ echo 'contents' >  foo.txt
    $ svn add foo.txt
    A         foo.txt
    $ svn ci -m ''
    Adding         foo.txt
    Transmitting file data .
    Committed revision 1.
    $ cd ../wc2
    $ echo 'other contents' > foo.txt
    $ svn up
    svn: Failed to add file 'foo.txt': object of the same name already exist
    $ cd ..
    $ rm -fr repo
    $ cp -R repo-template repo
    ...now forget to remove wc1 and wc2 before repeating]
    $ svn co svn://localhost wc1
    svn: Reference to non-existent revision '1' in filesystem
    'C:/Home/brane/src/svn/scratch/r/db'
    [1]+  Exit 58                 svnserve -d -r repo
Now, this falls into the "don't do this" class, and the crash doesn't 
happen consistently (I repeated this several times, usually remembering 
to delete wc1 and wc2 before checking out again). However, my assessment 
at this point is that:
    * Threaded svnserve is too flaky for a production environment, and
      we should not recommend to use svnserve on Windows the way it
      stands now
    * The fact that svnserve does not do any logging is a big problem here
My best guess is that #1862 is somehow connected to threaded svnserve 
instability; it seems that /all/ the reports were about svnserve!
I think we need to put a pretty hugh priority on stabilizing threaded 
svnserve, and adding server-side logging. Other problems aside, a server 
that doesn't produce logs is simply not ready for serious usage.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 18 03:52:26 2004