如果一个我想提交给SVN的文件经常更新,而我没有足够快地进行合并,会发生什么?

您看到这个问题时,似乎其他用户的情况与您的有所不同。不是这样的:问题不仅会影响到你自己,也会影响到所有其他用户。

这并不是说那些其他用户是精英群体的成员,他们只会导致问题的发生,但却从未亲身体验过。

换言之:

如果其他用户提交的次数足够多,以至于您无法提交您的更改,因为您必须不断更新,那么其他用户将无法提交 他们的 因为它们必须不断更新 他们自己 . 这将使所有的提交速度减慢到某一时刻某个人 将 能够在不需要更新的情况下提交他的更改,包括您自己。

医生:问题会自行解决的。

这通常被视为不是技术问题,而是“人”问题。它通常表示团队之间的通信失败,如果您发现自己处于这种情况,您应该与您的开发人员同事讨论如何更好地划分您的工作。

在大多数情况下,正如您所发现的,如果开发人员在同一时间在同一代码区域工作,而他们之间没有很好的协调,这是不现实的。

如果您真的以这样一种速度发生了这种情况,以至于您甚至无法提交您的更改,那么您已经超越了一个问题,进入了听起来像拒绝服务攻击的阶段:)。

首先,让我们假设这不是一场游戏,或者不是故意让你生气,在你生气的时候偷了你的好椅子……
但需要。;-)

如果发生这种情况,文件合并(大)很复杂,并且经常更新(也会变大)。

这个文件责任太重了,应该是 逻辑分裂 .

例如,对于整个应用程序,我们有一个这样独特的属性文件。它甚至崩溃了Eclipse来比较文件的两个版本!:-)所以一些开发人员不会比较和合并它,而是提交覆盖其他人的提交!我们分割了文件,每个模块一个属性文件,问题就消失了。

通常还有与此相关的其他问题,例如开发人员在一个巨大的文件中花费时间来查找他们想要的东西。分割解决方案解决了所有这些问题。

作为临时解决方案,您可以与人员同步 这样它们就为您提供了一个合并和提交的打开窗口。但问题通常会一直出现,直到团队确定地解决它。;-)

你不能锁定文件吗?

从SVN手册 http://svnbook.red-bean.com/en/1.5/svn.advanced.locking.html

svn lock banana.jpg -m "Editing file for tomorrow's release."

您可以尝试创建自己的分支,并针对它进行开发。完成功能后,将分支合并回头部。这样就可以推迟合并活动,直到完成工作。它并不能解决你的问题——你仍然需要进行合并——但是它确实推迟了时间,让你继续你的工作。也许,如果开发团队中的每个人都遵循这种做法——或者类似于只针对在同一领域工作的人的分支——那么在主开发分支中,文件一直在变化的问题就更少了。

虽然开发人员处理同一个文件是很常见的,但几乎没有发生过您需要连续两次执行更新的情况,因为在您完成合并之前有人提交了更新。

如果是这样的话,你要让5个人在同一个文件上工作(疯狂地做自己的权利),每5分钟进行一次微提交,我会说你还有其他问题需要担心,需要重组你的代码,并给他们(你的同龄人)一个权利“胡扯”。

奥伯曼说这是一个人际问题是对的,你需要找到更好的工作方式。然而,它也可能指向底层的体系结构问题。有这么多不同的开发人员经常需要更改的文件是个坏主意。

虽然我完全同意@orbman,但我可以建议使用“get lock”命令,但是 只有 作为最后的手段。

虽然我同意Orbman的观点——如果文件更新得太快,以至于你无法得到修改,那么根本的问题是开发人员的沟通——有一个技术解决方案。

SVN确实支持锁定文件的概念。您可以尝试锁定该文件,以便在合并更改时其他人无法提交。当您提交更改时,您将解除对文件的锁定,一切都应该正常。

也就是说,SVN允许人们打开锁。例如,如果有人在度假前锁定了一个文件,却忘记了将其解锁。因此,即使您确实锁定了它,也有人可以在您完成合并之前断开锁并提交代码。但是,如果有人在不首先检查的情况下破坏了命名用户的锁并提交,那么这可能是更糟糕的缺乏开发人员间通信的例子,而且更像是一个“人”问题。

如果文件经常被提交,也许它不应该受源代码管理?我对此的测试是:“我能对每一次修订(如标签)给出有意义的英文描述吗?”-如果没有,可能就不应该控制它。

这不是解决方案,而是 解决方法 使用 git-svn 作为Subversion存储库的本地客户端。