In message <firstname.lastname@example.org>, Ben Collins-Sussm
>This experiment is a red herring. Two svn clients cannot 'svn up' or
I was just trying to clarify what it was Jon meant because I
didn't understand what he was getting at and couldn't reproduce it
and thought it might be something that might affect me in the
future. The behavior as implemented was fine by me.
>'svn commit' in the same working copy directory at the same time,
>period. That's *exactly* the reason the client locks working copy
>directories when operating on them. It's a deliberate design.
That's fine. Just looking for a way to satisfy Jon's apparent desire
to perform two concurrent commits. I have no complaints and am
perfectly happy with the way it works now.
>So the "lock" error you're seeing has nothing to do with svn-commit.tmp
I don't think I claimed it did. I was trying to clarify what Jon was
talking about by reporting the behavior I encountered while trying to
reproduce the problem. It doesn't hurt to add your explanation,
but I still don't understand what Jon meant, which apparently you do.
I'm on time-delay, being subscribed to the digest so I didn't get to
see some of the follow-on comments until now. I still don't see how
the situation Jon described happens because if I commit two files from
the same directory that exist in two different directories (e.g.,
committing bar and foo/bar from ./) seperate svn-commit.tmp files get
created in ./ and foo/ for the commits. If I commit bar and foo/bar with
one commit and foo/foo with another, the lock in foo/ prevents the second
commit. And if for some reason I have svn-commit.tmp lying around in a
directory after a commit, the next commit in that directory uses
svn-commit.2.tmp. Regardless, it appears to be a non-problem so no use
spending any more breath on it. Sorry for adding to the noise.
Just trying to be helpful.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat May 8 01:08:43 2004