I attempted to first raise this issue on the subversion usersı mailing list
a week or two ago, but got no response. Iım pretty confident that this is a
bug or at least it is an undocumented change in behavior from prior
releases.
We have a setup where there is a centralized working copy accessed by
multiple users. As a result, having the correct permissions set on things
makes or breaks this working model. Our working copy directories are all
set up to have read+write user and group permissions.
We are working with a number of binary files that we have set up to have
needs-lock properties. Prior to subversion 1.4.0, the behavior of the Œsvn
lockı command was such that the user executing the command would assume
ownership of the file and get write permissions. Effectively, it would
delete the original file in the working copy and then copy a fresh version
in place. (at least this is what it appears to do) It works this way in
both 1.2.3 and 1.3.0. Meanwhile, svn unlock leaves the file read-only
across the board.
With 1.4.0, it now reports an error that it canıt change the file
permissions. (I believe it is also the same with 1.4.2) This is a pretty
significant change in behavior. I imagine that most people havenıt noticed
since most people use private working copies.
Can somebody confirm that this is a bug? It is very easy to reproduce. We
managed to work around the issue, but itıs an ugly hack to a wrapper script
to move the file and copy it back so that the user can assume ownership and
call Œsvn lockı. If somebody wants to lock a large number of files, it
takes a lot longer now.
Thanks,
Steve Bakke
Received on Thu Dec 14 20:36:03 2006