Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
If you want version control that behaves like VSS, why don't you just continue to use VSS? – Tim Long May 5 '10 at 22:16
up vote 1 down vote accepted

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)

share|improve this answer
Problem is, the developers have grown accustomed to things automatically locking and unlocking when they check-out or undo checkout with VSS. I know we will run into issues with this if you cannot replicate the functionality. +1 for pointing out the "auto-close if no errors" feature of Tortoise. I missed that! – Josh Stodola Aug 7 '09 at 15:42
we (and I think every other VSS shop) doesn't even know there is an alternative. Just explain it to them and they will almost certainly see the benefits. Especially when you explain you never need to ask someone to unlock files again. They love that. – gbjbaanb Aug 9 '09 at 1:19
I wish that was an option! – Josh Stodola Aug 10 '09 at 14:09

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.