views:

191

answers:

2

We have just started using VisualSVN, TortoiseSVN and ankhSVN plug-in to handle our source control. Initially we were good with the Copy-Modify-Merge style, but we have now found a need to move to the Lock-Modify-Unlock method. But we already have like 15 projects in our repository that follow Copy-Modify-Merge.

What do I need to do to configure our repository to require locks for the existing projects and any projects that will be added in the future. I have seen the documentation on svn:needs-lock but I don't understand how to use this to move our shop to Lock-Modify-Unlock.

Can anyone please give me the "for dummies" explanation of how to set up VisualSVN server as well as our client machines to require locking for the existing projects and newly added projects?

+2  A: 

Subversion does not offer a strong lock-modify-unlock mechanism. But, if you right click on any file in subversion you get the option to lock it. This prevents anyone else from checking in until they have the lock or the lock's been released.

You can mark files as needing a lock by setting the svn:needs-lock property, see here:

http://svnbook.red-bean.com/en/1.4/svn.advanced.locking.html#svn.advanced.locking.lock-communication

and

http://svnbook.red-bean.com/en/1.4/svn.ref.properties.html

You don't have to set it for every file in the project, you can have it for individual files quite happily.

However, the edit-merge-commit operation is the default in every modern source control system for a reason. Even TFS. Again, I recommend Eric Sink.

Jim T
When you set svn:needs-lock, AnkhSVN behaves pretty much the same as when using VSS, showing a lock dialog when you're about to edit an unlocked file.
Sander Rijken
A: 

  Well, I guess i must make a point in here, to support the request.
  Most of the times, you are not in quite as great work places as we would expect, places where code usually requires a lot of refactoring, and usually are us, those who study, that think about the archtecture and go for the bold and the new, to end up this cycle of never ending refactoring.
  Usually as well, when we are reafctoring some poor man's implementation of data layer or similar, the bastard goes and changes the bloody file, in a such hideous way ( because essentially it does not work properly, for the obvious reasons), that then, you end up with a rework.
  You have to do it yourself, against the tide, against all the odds, because, that man will never do as good as you would expect.
  I find myself in a company where I face such developers. And they have ego, and they have their reasons (and their reasons are usually time, which is a lie, because we all have the same ammount of time, it is just that they don't dedicate themselves, just go and finish it, no thoughts, no ideas, just monkey typing). And a little support boss.
  Usually It is up to me, in my company, to "make things work", and I would love to be able to lock the files everytime I need to re-do something, so i don't have to re read, or merge that bastard's "new" implementation.

Please note that this is just a case, my case anyhows, to support swolff1978's request.

NoProblemBabe