如何将 VisualSVN 服务器从复制-修改-合并重新配置为锁定-修改-解锁？
我们刚刚开始使用 VisualSVN、TortoiseSVN 和 ankhSVN 插件来处理我们的源代码控制。最初我们很喜欢复制-修改-合并风格，但现在我们发现需要转向锁定-修改-解锁方法。但我们的存储库中已经有大约 15 个遵循复制-修改-合并的项目。
我需要做什么来配置我们的存储库以要求锁定现有项目和将来添加的任何项目。我看过关于 svn:needs-lock 的文档，但我不明白如何使用它来将我们的商店移动到锁定-修改-解锁。
任何人都可以给我“傻瓜式”解释，说明如何设置 VisualSVN 服务器以及我们的客户端计算机，以要求锁定现有项目和新添加的项目吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Subversion 不提供强大的锁定-修改-解锁机制。但是，如果您右键单击 subversion 中的任何文件，您可以选择锁定它。这可以防止其他人在拥有锁或锁被释放之前签入。
您可以通过设置 svn:needs-lock 属性将文件标记为需要锁定，请参阅此处：
http://svnbook.red-bean.com/en/1.8/svn.advanced.locking.html#svn.advanced.locking.lock-communication
和
http://svnbook.red-bean .com/en/1.8/svn.ref.properties.html
您不必为项目中的每个文件设置它，您可以非常愉快地为单个文件设置它。
然而，出于某种原因，编辑-合并-提交操作是每个现代源代码控制系统中的默认操作。甚至TFS。我再次推荐 Eric Sink。
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.8/svn.advanced.locking.html#svn.advanced.locking.lock-communication
and
http://svnbook.red-bean.com/en/1.8/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.
好吧，我想我必须在这里指出一点，以支持这个请求。
大多数时候，你所在的工作场所并不像我们想象的那么好，代码通常需要大量重构，而通常是我们这些学习者、思考架构并追求的人大胆而新颖，结束这个永无休止的重构循环。
通常情况下，当我们重新构建某个可怜人的数据层或类似实现时，混蛋会以如此可怕的方式更改该该死的文件（因为本质上它无法正常工作，因为明显的原因），然后，你最终会返工。
你必须自己去做，逆潮流，克服一切困难，因为，那个人永远不会做得像你期望的那么好。
我发现自己所在的公司面临着这样的开发人员。他们有自我，他们有他们的理由（他们的理由通常是时间，这是一个谎言，因为我们都有同样多的时间，只是他们不奉献自己，只是去完成它，没有想法，没有想法，只是猴子打字）。还有一个小支持老板。
通常，在我的公司里，“让事情顺利进行”取决于我，我希望每次需要重新做某事时都能锁定文件，这样我就不必重新做阅读或合并那个混蛋的“新”实现。
请注意，这只是一个案例，无论如何，是我的案例，以支持 swolff1978 的请求。
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.