SVN合并——哲学
我们正在考虑限制颠覆项目中的合并点。
背后的想法是保持合并更加整洁，因为我们担心 大量刚接触 svn 的开发人员，我们可能会得到不同合并的蜘蛛网 点。
我们害怕所有不同的副作用，所以这样的限制将帮助我们把一切准备就绪。
作为一个基本概念，我们决定仅允许在根上分支并仅在分支顶部进行合并。这让一切都变得美好。但是......
但是由于一些开发人员团体在整个主干上使用了 10％，因此允许他们仅在其上进行分支似乎是合理的。
然后乐趣就开始了。如果我们给予他们自由意志，那么合并可能会在任何地方发生。 我真的很害怕。这就是我提出这个问题的方式:-)
您如何看待设置这些东西的干净方法？
谢谢！
We are thinking over restricting merge points in our subversion project.
The idea behind is to keep merging more tidy, as we are afraid that with
significant number of developers new to svn, we might get cobweb of different merge
points.
We afraid of all different side effects, so such restrictions will help us to have everything in place.
As a basic concept we decided to allow branching only on root and merge only on the top of the branch. This make all nice. But....
But as some of developer groups use 10% on overall trunk, it seems reasonable to allow them to branch only on.
Then the fun starts. If we give them freewill then merging could occurs everywhere.
I am really afraid of that. That is how I came to the issue:-)
How would you see the clean way of setting the things up?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
除非您想限制对特定分支的提交访问，否则在 Subversion 中没有简单的方法可以做到这一点。
首先，通常只想将合并限制为一小部分文件。如果只允许在项目级别进行合并，我就无法在需要时有选择地进行合并。
另一个问题是 svnlook 不会告诉您文件被更改的原因。即使您可以阻止某些文件上有 svn:merge-info 的提交，用户也可以轻松使用
--ignore-ancestery参数，不仅进行合并，甚至不记录它的完成情况这会让你变得更糟，因为你不知道合并已经完成。请记住，如果您阻止用户做他们认为需要做的事情，他们就会想方设法绕过您的限制。最好的办法是信任您的开发人员，并让他们接受培训，了解如何以及为何应在 Subversion 中进行合并。
请记住，在颠覆方面，您是无所不知的上帝。在你无所不知的存在面前，没有什么是隐藏的。如果开发人员确实进行了古怪的合并，您会通过“svn 日志”知道。这种力量让开发人员保持一致。如果您让技术主管理解为什么您需要合并为一个逻辑一致的庄园，则尤其如此。毕竟，如果合并出现问题，受影响的是开发团队。
Unless you want to restrict commit access to a particular branch, there's no easy way of doing this in Subversion.
First of all, it's common to just want to limit your merges to a small sub-set of files. If you only allow merges at the project level, I can't selectively merge when needed.
The other problem is that
svnlookdoesn't tell you why a file was changed. Even if you could prevent commits if certain files have svn:merge-info on them, users could easily use the--ignore-ancesteryparameter and not only do the merge, but not even record it was done which will mess you up even worse since you don't have information that the merge was even done. Remember that if you prevent a user from doing what they feel they need to do, they'll find ways around your restriction.The best thing to do is to trust your developers, and have them trained how and why they should do merges in Subversion.
Remember that you are an all seeing God when it comes to Subversion. There is nothing hidden from your all knowing presence. If a developer does do a wacky merge, you'll know via the "svn log". That power keeps developers in line. This is especially true if you get the tech leads to buy in on why you need to merge in a logical and coherent manor. After all, it's the development teams that suffer if merging goes awry.