On Nov 13, 2007 11:43 AM, Moore, Tom <Tom.Moore@aig.com> wrote:
>
> Lets say we have a scenario where file changes can't be merged, such as
> image files.
>
> User A locks car.jpg and proceeds to work on the image
>
> User B does a svn update to update their working copy in order to work on
> the image.
>
> If the svn:needs-lock property is attached to car.jpg, then User B has a
> read-only copy. On noticing that the file is read-only, User B can run svn
> status –u on the file and note that the file is locked. This is the method
> suggested to have the subversion software communicate a lock, and is the
> best case scenario for two users working on a locked file.
Even if the file isn't locked by anyone, everyone sees it as read-only
in their WC (unless they've unset the read-only attribute). User B can
run svn lock to attempt to get a lock on the file, and they will be
informed that it's already locked by another user. Or, he can just run
svn st -u to find out that it's locked.
> A worse case scenario is that the svn:needs-lock property was never set.
> User B has no clue while working on the file that the file is locked.
But if he runs svn st -u he will learn that it's locked. The local
read-only attribute does *not* indicate whether the file is locked by
someone else. Further, if someone breaks my lock, the file will be
read/write for me *and* the person who stole the lock.
> If I have done an update, then locally then the working copy knows that the
> file is locked. Doing a svn status –u car.jpg returns :
>
> O 11 car.jpg
>
> That O means its locked by other. User B then has to run svn info against
> the repository path for car.jpg to see who it was that had the file locked.
You don't have to do svn up first. svn st -u checks with the server
for any updates which the local WC is not aware of.
svn lock <local path> will also tell you who has the file locked. svn
info <url> isn't the only way.
> Since the knowledge that the file is locked was passed to the working copy
> on the update, I think it should have been spelled out in the update output
> messages. The best scenario would also print the name of the user that has
> the file locked.
But the instant that update is complete, any lock data can be out of
date. One should always check w/ the server (svn st -u) to learn the
current lock situation for a file, not rely upon local WC info.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 13 18:02:55 2007