Locking

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.

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.
Upon commit, User B discovers the commit failed with a SVN error (ie
svn: PUT of
'/svn/project1/!svn/wrk/64bad3a9-96f9-0310-818a-df4224ddc35d/car.jpg':
423 Locked (http://subv.cars.com)
 

Why is the lock information so obscure?

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.

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.

Ok, so sometimes the logs are long and we can miss this information.
The user still edits this file and saves it. If the user is
disciplined and does another SVN update before committing in order to
determine if there were changes, then the update output messages should
again warn them that the file is locked and who has it locked.

If the user is not disciplined, or just missed the output from the
update attempt, or decides for some reason to ignore it and attempts a
normal commit (not forced) of this file then they get the commit failure
message. This message is returned as an error, however the failure of
the commit is NOT an error. It is correct and expected behavior. The
commit failure in this case should be more explicit, perhaps something
in the form of:

Commit of car.jpg failed as car.jpg is currently locked by User: User A

Lastly, I think that svn status -u car.jpg should not only indicate that
the file is locked, but also print the name of the person who has it
locked.

Is there agreement on my statements, or am I barking up the wrong source
tree?

Tom

 
Received on Tue Nov 13 17:48:37 2007