I have Visual SVN server running on a Windows machine. I am using the VisualSVN client that integrates into Visual Studio. Previously, we used Visual SourceSafe, which had the lock-modify-unlock versioning model. Despite the drawbacks of this model, it is what we are used to, and we want identical behavior from Subversion. In short, we do not trust the merging.
I have done the following…
- Enabled auto-props in [miscellany] section of config:
enable-auto-props = yes - Added entry to [auto-props] to force needs-lock on all files:
* = svn:needs-lock=* - Disable no-unlock to automatically unlock file on commit:
no-unlock = false - Changed TortoiseSVN settings to not show the lock dialog when locking files
- Changed TortoiseSVN to auto-close dialogs if no errors.
And I have the following issues…
- When I revert my changes, the lock is not released. It should be. Is there any way I can force it to unlock when I revert?
- Edit: fixed! Everytime I begin to make a change, it automatically gets a lock, but it presents me with a dialog saying "Lock Finished!". This dialog only gets in the way. It would be nice to be able to assume that the lock was completed successfully. Is there a way to hide this dialog, and only display it if an error occurs.
How can I resolve these issues? I really don't want to hear a sales pitch on why we should use copy-modify-merge, please just help me resolve the issues.
Best Answer
I think your issues are with VisualSVN, you need to contact them to configure the product to not show the dialog and to automatically unlock on revert. Stefan is quite good about making fixes, and it sounds like the no-unlock config item should also apply to revert as well as commit. Note that the revert functionality does not contact the server, so he might consider that an undesirable change.
In most cases the lock is a manual thing you need to explicitly lock and unlock, so most people using it would want to have to ensure they unlock.
If the 'lock dialog' is a Tortoise thing, you can configure the dialogs to auto-close if there's no errors. Again, send a message to the mailing list to see if everyone else wants this change.
PS. When I converted to SVN from VSS, I decided to go with the copy-merge-modify approach, and then slap locks on everything if it didn't work out well. Nobody has complained, and they all like the system (once I'd told them not to try resolving conflicts with binary files)