Subversion Lock is based on both working copy and user

2 05 2009

Scenario: User ‘sankalp’ locks a file in his working copy and tries to commit some changes to the locked file from another working copy that was checked out under same username.

Result: Commit would fail, because the later working copy doesn’t get the file lock, only the first one does.

I stumbled upon this while locking a file via URL path, using FinalBuilder Subversion file lock (Actually ‘Subversion Generic‘ action). Although the lock is successful and can be seen from repository browser client, the working copy didn’t reflect it. So I had to lock the file based on its working copy path, and not based on its URL path. This made me realize that locks are specific to working copies, apart from being exclusive to users.

Also, if somehow you delete the working copy that had locked a file and cannot restore it back, the only way out seems to be breaking a lock on that particular file. Or is there any other way out?

Sources:

1. http://groups.google.com/group/tortoisesvn/browse_thread/thread/dbf3269ae304761d
2. http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-locking.html

Advertisements




Different version formats for .Net & win32 components

9 03 2009

For a win32 dll or exe , the  fileversion attribute means following:

majorversion.minorversion.releaseversion.buildversion

Whereas, a .Net component has different interpretation of these numbers.  i.e.

majorversion.minorversion.buildnumber.revision

This means, if you have an  exe or dll with fileversion 1.0.0.2 from a vc++ project, then corresponding assemblyversion for a .Net exe or dll for same build would be: 1.0.2.0.

This was causing little confusion while I was working with FinalBuilder to version all project executables before applying MSBuild.  Right now, I have kept consistent version format for all project types  and am interpreting them as win32 style version information.

Any opinions?