BUG: svn st => svn: Can't open '.svn/tmp/mixed.pl.tmp': No such file or directory

This is reproducible. First a word about all the systems involved:

The repository is 1.1.x (r10858) on Linux (recent Debian testing).
--fs-type=fsfs, if it matters.

The client is Cygwin's released version of 1.0.6, running on Win2K
with Service Pack 4.

The working copy lives on an old RedHat box running Samba 2.2.7a, and
is accessed, naturally, via SMB. (kernel 2.4.20-30.9smp, if it
matters)

First I'll describe in vague prose what I'm doing; then I'll include
two shell scripts that more-or-less reliably repro the problem.
("more-or-less" because they may require a tiny amount of tweaking to
accommodate the name of the Windows drive that represents the Samba
directory, the name of the repository's server, and other similarly
tiny things).

I've got a repository on the new Linux box, naturally enough. My
working copy is on the old Linux box, but I'm accessing it (* sigh *)
from Cygwin, via SMB.

I've got "auto-props" enabled, so that Perl scripts get svn:eol-style
"native".

I attempt to check in a Perl script whose line endings are
inconsistent. The checkin attempt naturally fails with the "line
endings are inconsistent" message. No problem there. But: at that
point, my working copy is, as Sussman puts it, horked; `svn st' yields
the scary error message in the Subject: line.

    Now, as it happens, this bug, _as described above and in the
    scripts below_, isn't particularly nasty, since `svn cleanup' puts
    everything back into shape again. However, what I'm describing
    here isn't exactly what I originally saw; unfortunately I haven't
    figured out how to repro that original bug, which is a shame since
    it WAS nasty (`svn cleanup' didn't help; I saw something about
    `couldn't access `.svn/lock' because "No such file or directory"'
    even though that file clearly existed). So I'm hoping that
    someone will look at what I've described, find the responsible
    bug, and then realize that that very bug could indeed have been
    responsible for the nastier behavior that I only vaguely remember.

Anyway, enough blather. Here are the scripts:

I call this "server.sh":

    #!/bin/bash

    set -e

    cd

    rm -rfv $HOME/silly-repos

    ~svn/local/bin/svnadmin create --fs-type=fsfs $HOME/silly-repos

    echo '[general]' > $HOME/silly-repos/conf/svnserve.conf
    echo 'anon-access = write' >> $HOME/silly-repos/conf/svnserve.conf

    # I'm only using a non-standard port because the box on which the
    # repository lives is already running another svnserve on the standard
    # port. I doubt the port number has anything to do with this bug.
    ~svn/local/bin/svnserve -r $HOME/silly-repos --foreground --daemon --listen-port=9918

And I call this "client.sh":

    #!/bin/bash

    port=9918
    server=eng01

    c=$HOME/.subversion/config
    b=$c.bak

    if [ -f $b ]; then
        echo will not clobber $b ;
        exit
    fi

    mv $c $b

    echo [miscellany] > $c
    echo enable-auto-props = yes >> $c
    echo [auto-props] >> $c
    echo '*.pl = svn:eol-style=native' >> $c

    # Of course you'll have to change this letter to match whatever
    # network drive you've created.
    
    cd e:/ # <---------------------------- EDIT THIS LINE

    w=silly-wc

    rm -rf $w
    svn co svn://$server:$port $w
    cd $w
    echo -e A line without a CR > mixed.pl

    svn add mixed.pl
    svn -m "" ci

    echo -e I gots a CR\\r >> mixed.pl
    svn -m "" ci
    svn st

Run `server.sh' on a recent Linux box with a 1.1.x svn. Then by hand
set up a SMB drive to the older linux box, something like this:

        $ net use \* \\\\eng01\share

Then whatever letter that drive is, edit the one line in "client.sh"
that says "EDIT THIS LINE" to match.

Then run server.sh on the server, and client.sh on the client; you'll
see the client output

    Transmitting file data .svn: Commit failed (details follow):
    svn: Inconsistent line-endings in source stream
    svn: Can't open '.svn/tmp/mixed.pl.tmp': No such file or directory

That last line is the bug.

Now to demonstrate that the problem is indeed related to SMB, re-edit
the client script by changing the drive letter so that it now points
to a local file system. Kill the server process, re-start it, and
re-run the client script; you'll then see just the "Inconsistent
line-endings" message, but you will not see the last "Can't open"
message.

-- 
Asking the Iraqi people to assume Saddam's debts
is rather like telling a man who has been shot in the head
that he has to pay for the bullet.
        -- James Surowiecki
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org