wc.db is locked after update until the dialog is closed

[Jens Wilhelm]

I have an post-update client hook script that needs access to wc.db.

This doesn't work because the database is locked until the Dialog is closed.

My workaround is to start another script waiting for getting access to the database.

Question to the developers: would it be possible to release the locking before calling the post-update script?

[Stefan]

what are you trying to do with the wc.db and how?

[Jens Wilhelm]

Subversion does not support storing file timestamps (last modification) by itself.

Because the file timestamps in my case are meaningfull for some third party software, I store and retrieve them in the repository using properties.

A subversion client sets the filestamp to the date and time of the last update (or to the time of the commit of the revision). To get a very fast method for checking, if a file in a working copy ist changed or not, this filestamp of the last update ist stored to the wc.db by the subversion client.

My post-update client hook script sets the file timestamps of the updated files to the values that are stored in the property. This means that a check of the modification state will find a difference in timestamps between the file and the wc.db. To get out if there really was a modification of the file, the file has to be read and compared completely do the stored copy in the pristine folder. In my case this has to be done often for Gigabytes of binary data.

So I needed a way to synchronize the entries of last modification in the wc.db with the changed timestamps of the files in the working copy. This can be done by a cleanup using the "Fix time stamps" option or by setting values by sqlite3 directly.

If the post-update script tries to do that (may be by calling TortoiseProc.exe /path:"<path>" /command:cleanup /nodlg /noui /fixtimestamps), one gets an error because the database is still locked from the update.

My workaround is to start another script, waiting in a loop until it gets access to the database. Usually the database will be unlocked after closing the update dialog window.

If the cleaning command starts interactive (without the options /nodlg /noui) it seems that the TortoideProc gets the database unlocked without closing the update dialog window.

My question is: are there reasons to get the database locked until finishing the post-update hook script or could it be unlocked by TortoiseProc before the script is called ?