如果我想要提交到 SVN 的文件更新太频繁，以至于我无法足够快地进行合并，会发生什么情况？
考虑一种情况。我想将更改的文件提交到 SVN，并在我签出后看到其他人提交了相同的文件，因此我必须“更新”并合并更改。当我这样做时，有人再次提交相同的文件，因此当我尝试提交合并的文件时，我必须再次更新。
现在，如果其他用户提交得足够频繁，看起来我将永远无法提交我的更改。真的是这样吗？在实际的开发环境中这个问题是如何解决的呢？
Consider a situation. I want to commit a changed file to SVN and see that someone else committed the same file after I checked it out, so I have to "update" and merge changes. While I'm doing that someone commits the same file again, so when I try to commit the merged file I have to update again.
Now if other users commit often enough it looks like I will never be able to commit my changes. Is that really so? How is this problem solved in real development environments?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
这通常被视为不是技术问题，而是“人”问题。这通常表明团队之间沟通失败，如果你发现自己处于这种情况，你应该与你的开发人员同事讨论如何更好地划分你的工作。
正如您所发现的，在大多数情况下，如果开发人员之间没有良好的协调，那么他们同时在同一代码区域工作是不切实际的。
如果您确实以如此快的速度发生这种情况，以至于您甚至无法提交更改，那么您已经超越了问题，而听起来像是拒绝服务攻击:)。
This is usually viewed as not a technical problem but a "people" problem. It usually indicates a failure in communication among the team, and if you find yourself in this situation, you should discuss with your fellow developers how to better partition your work.
In most cases, as you are finding, it is not practical for developers to be working in the same area of code at the same time without good coordination between them.
If you actually have this happening at such a rate that you can't even commit your changes, you have moved beyond a problem to what sounds like a Denial-Of-Service attack :).
首先让我们假设这不是一个游戏，或者不是故意让你生气并在你愤怒地出去时偷走你漂亮的椅子......
但需要。 ;-)
如果发生这种情况，文件合并起来很复杂（大）并且更新频繁（也会变大）。
这个文件承担了太多的责任，应该逻辑分割。
例如，对于整个应用程序，我们有一个像这样的独特属性文件。比较文件的两个版本甚至使 Eclipse 崩溃！ :-) 所以一些开发人员不会比较和合并它，而是提交覆盖其他人的提交！我们拆分文件，每个模块一个属性文件，然后问题就消失了。
通常还存在与此相关的其他问题，例如开发人员浪费时间在巨大的文件中查找他们想要的内容。拆分解决方案解决了所有这些问题。
作为临时解决方案，您可以与人员同步，以便他们为您提供一个开放的窗口来合并和提交。但问题通常会不断出现，直到团队明确解决为止。 ;-)
First let us suppose it is not a game, or not done otherwise on purpose to make you angry and steal your nice chair while you went out with anger ...
but needed. ;-)
If this happens, the file is complex to merge (big) and updated very often (will also get big).
This file carries too much responsibility, it should be split logically.
For example, we had a unique property file like this, for the whole application. It even crashed Eclipse to compare two versions of the file ! :-) So some developpers would not compare and merge it, but commit overriding other's commit ! We split the file, one property file per module, and the problems went away.
There are usually other problems associated with this one, such as developpers loosing time to find what they want in a huge file. The split solution solves all these problems.
As a temporary solution, you could synchronize with the people so that they give you an open window to merge and commit. But the problem typically keeps appearing until the team solves it definitely. ;-)
你就不能把文件锁起来吗？
来自 svn 书籍 http://svnbook.red-bean。 com/en/1.5/svn.advanced.locking.html
Couldn't you just lock the file?
from the svn book http://svnbook.red-bean.com/en/1.5/svn.advanced.locking.html
您可以尝试创建自己的分支并针对该分支进行开发。完成功能后，将分支合并回头部。这样，您就可以推迟合并活动，直到工作完成。它并不能解决你的问题——你仍然需要进行合并——但它确实推迟了它并让你继续你的工作。也许如果开发团队中的每个人都遵循这种做法——或者类似的做法，仅针对在同一领域工作的人员进行分支——那么主开发分支中文件不断变化的问题就会减少。
You might try creating your own branch and developing against that. Once you have completed your feature, then merge your branch back into the head. This way you defer your merge activities until your work is complete. It doesn't solve your problem -- you still have to do the merge -- but it does defer it and let you get on with your work. Perhaps if everyone on the development team followed this practice -- or something similar with branches only for people working on the same areas -- you'd have fewer issues with the files changing all the time in the main development branch.
您看待问题的方式就好像其他用户的情况与您的情况有所不同。事实并非如此：这个问题不仅会影响您自己，还会影响所有其他用户。
这并不是说那些其他用户是精英群体的成员，他们只会导致问题，但自己却从未遇到过问题。
换句话说：
如果其他用户提交的频率足够高，以至于您将永远无法提交更改，因为您必须不断更新，那么其他用户也将无法提交他们的更改，因为他们必须不断更新自己。这将减慢所有提交的速度，使某人在任何给定时间都能够提交其更改而无需更新，包括您自己。
tl;dr：问题会自行解决。
You are looking at the problem as if the situation for those other users is somehow different from yours. It is not: the problem will affect not only yourself, but all those other users, too.
It's not as if those other users were members of an elite group that can only cause the problem, but never experience it itself.
In other words:
If other users commit often enough that you will never be able to commit your changes because you have to constantly update, then other users will not be able to commit their changes, either, because they will have to constantly update themselves. This will slow down all commits to a point where at any given time someone will be able to commit his changes without having to update, including yourself.
tl;dr: the problem will fix itself.
虽然开发人员处理同一个文件是相当常见的，但几乎不会发生您需要连续执行两次更新的情况，因为人们在您有机会完成合并之前就进行了提交。
如果是这种情况，并且您有 5 个人处理同一个文件（这本身就是疯狂的），每 5 分钟进行一次微提交，我会说您还有其他应该担心并需要重组的问题并给他们（你的同事）一个正确的“胡言乱语”。
Whilst it is fairly common for developers to be working on the same file, it hardly ever happens that you need to perform an update twice in a row, because of people committing before you had a chance to finish the merge.
And if that's the case, and you were to have 5 people working on the same file (crazy in its own right), making micro-commits every 5 minutes, I'd say you got other problems you should worry about and need to restructure your code as well as give them (your peers) a right 'bollocking'.
OrbMan 说得对，这是一个人的问题，你需要找到更好的工作方式。然而，它也可能指出了潜在的架构问题。拥有一个需要由这么多不同的开发人员经常更改的文件是一个坏主意。
OrbMan is right to say that this is a people problem, and you need to find a better way of working. However, it may also point to an underlying architectural issue. It is a bad idea to have a file which needs to be changed so often by so many different developers.
虽然我完全同意@OrbMan，但我可以建议使用“Get Lock”命令，但仅作为最后的手段。
While I do totally agree with @OrbMan, I can suggest using "Get Lock" command, but only as a last resort.
尽管我同意 OrbMan 的观点 - 如果文件更新得如此之快以至于您无法获取更改，则根本问题是开发人员沟通之一 - 有一个技术解决方案。
SVN 确实支持锁定文件的概念。您可以尝试锁定文件，以便其他人在您合并更改时无法提交。当您提交更改时，您会解锁文件，一切都应该没问题。
也就是说，SVN 确实允许人们破解锁。例如，如果有人锁定了文件并在度假前忘记解锁。因此，即使您确实锁定了它，有人也可能会在您完成合并之前打破锁定并提交他们的代码。但是，如果有人在没有先与指定用户检查的情况下打破了指定用户的锁定并提交，这可能是开发人员之间缺乏沟通的更糟糕的例子，并且更多的是“人”问题。
Although I agree with OrbMan - if the file is being updated so quickly that you can't get your changes in, the underlying issue is one of developer communication - there is a technical solution.
SVN does support the concept of locking a file. You could try locking the file so that others cannot commit whilst you are merging you changes. When you commit your changes, you unlock the file and all should be OK.
That said, SVN does allow people to break locks. In case someone locked a file and forgot to unlock it before going on holiday, for example. So even if you do lock it, someone could break the lock and commit their code before your done merging. But if someone breaks a named users lock and commit without checking with them first, that is probably an even worse example of lack of inter-developer communication and again is more of a "people" problem.
如果文件经常被提交，也许它不应该受到源代码控制？我对此的测试是：“我能否始终为每个修订版（即标签）提供有意义的英文描述？” - 如果不是，它可能不应该被控制。
If the file is being comitted that often, maybe it shouldn't be under source control? My test for this is: "Can I always give a meaningful English description of each revision (i.e. a tag)?" - if not, it probably should not be controlled.
这不是解决方案，而是一种解决方法：使用 git-svn 作为 Subversion 存储库的本地客户端。
This is not a solution, but a workaround: use git-svn as a local client to Subversion repository.