Bert Huijben <b...@qqmail.nl> writes: > Subversion still reports the working copy as ‘locked’ in this case, just > like Subversion 1.0-1.6 reported this case when we still used 'loggy’ > operations. So there is still a quite visible status that tells you that > there is something to be done. > (Every directory shows as status write locked; not unmodified or something) > > > The change in 1.7 was an implementation detailed that caused us to break > operations that opened the database… But if your client opened it earlier > (or while there were temporarily no workqueue items… as happens every time > the workqueue is run), it could just open it… and use it during all future > operations. > > Blocking out just initial db opens, but not blocking new operations when a > db is open (e.g. when cached in svn_client_ctxt’s svn_wc__db_t instance) is > in my opionion more inconsistent than the current behavior which does a > check on obtaining the write lock.
Indeed, I see that non-readonly operations are locking the necessary portions of the working copy and that 'svn st' reports it if the operation is aborted: svn-1.9 co https://svn.apache.org/repos/asf/subversion/trunk/ . svn-1.9 up -r {2015-05-01} ^C svn-1.9 st ! L . L build L build\ac-macros L build\generator L build\generator\swig L build\generator\templates L build\generator\util L build\hudson L build\hudson\jobs L build\hudson\jobs\subversion-1.6.x-solaris L build\hudson\jobs\subversion-1.6.x-ubuntu L build\hudson\jobs\subversion-doxygen L build\hudson\jobs\subversion-javadoc L build\hudson\jobs\subversion-trunk-solaris L build\hudson\jobs\subversion-trunk-ubuntu L build\win32 L contrib L contrib\cgi L contrib\client-side L contrib\client-side\emacs ... Just to clalify, the change got caught by our test suite, and I wanted to make sure it's not something unexpected. Thanks again for shedding light on this. Regards, Evgeny Kotkov
