Bert Huijben <bert_at_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
Received on 2015-05-14 12:44:52 CEST