颠覆和混合修订：破坏版本的配方？

Question

我只是在使用TFS一段时间后再回到颠覆，一般我已经退出了:)

有一点我记得不同。我不记得是否能够从过时的工作副本中提交。或者也许我的记忆让我对“过时”的定义失败了。我认为“过时”意味着自从我上次更新我的工作副本以来，任何文件都被触摸了，而不仅仅是我触摸过本地触摸的文件（我称之为冲突）。

我认为这是一个问题的原因是，如果我可以在不先与其他人所做的更改集成的情况下提交我的更改，那么就可以很容易地“破坏构建”。

这种混合修订的东西是不是很激动还是仅仅是我？

Answer 1

是你，因为它一直是这样的; - ）

如果您尝试提交的任何项目已过时，您的提交将失败，并且存储库有一个“常规”修订号，但只要您要提交的所有内容都是 - 到目前为止，你可以提交。这并不意味着它当然是最好的做法。

请记住，svn不仅用于软件开发。一般来说，这种能力可能很好。

此外，AFAIK TFS在这方面的工作非常相似，对吗？

Answer 2

简短回答：一般来说，制作一些旨在让开发人员的办公桌远离新签出标签的构建是一种很好的做法。如果可能，在另一台机器上。

如果您遵循该规则，您可以睡得更好。

更长的答案：这意味着，在发布之前，您必须更新您的工作副本，构建它，运行所有测试，当您满意时，从中复制（标记）。然后指示构建机器通过此标记的新签出进行构建。您将构建的结果移交给测试部门。

如果您以后需要检索特定版本，则始终要检查该标记。如果该版本标记为“tags / release_4.2.0”并且您需要进行修复，请将标记复制到某个分支（“branches / release_4.2.1”）并在那里修复。当您确定它按预期工作时，然后将分支移动到“tags / release_4.2.1”。再次，让构建机器签出标记，构建代码，并将其交给测试。

Answer 3

承认这种“混合”修订的能力并没有让我觉得本身就是不安全的。即使您在执行提交之前使用的VCS要求所有文件都是最新的，VCS也无法验证您是否实际编译了代码或运行了所有单元测试。开发人员和持续集成系统应该涵盖这类事情。

Subversion拥有一个以文件为中心的世界观，就像它的CVS祖先一样。您可以查看特定文件的特定修订版，而无需触及其周围的任何文件。这与其他系统（例如Git（我不熟悉TFS的细节））形成对比，其中不跟踪单个文件的特定检出修订。相反，整个结帐是在其历史记录中的特定点处的存储库视图，并且与其的任何偏差都被视为新的更改。当然，您仍然可以根据自己的喜好随意提交新的更改，如果不选择正确的组合，可能会破坏构建。

Answer 4

不，你不能提交svn过时的文件。读这个： http://subversion.tigris.org/faq.html#wc-out-of-date

Answer 5

感谢您清理那些家伙。考虑一下，我想我的建议无论如何都会实现客户端..而且我完全明白，仍然需要开发人员确保所有内容都能编译。实际上，这并不是一个大问题，但是有几次开发人员在没有首先更新他的工作副本的情况下提交工作，导致头部修改破损。

另一方面，来自Tortoise的这个例子怎么样：http://tortoisesvn.net/node/13

“现在，如果您修改File2并尝试提交，它将失败。客户端告诉存储库File2处于修订版2并进行本地修改，但存储库已经处于修订版3.如果您随后进行更新，File2也将在第3版（当然，您的本地更改仍将在那里）。“

我实际上并没有收到“过时”的消息，但您应该认为在某些情况下会出现这种情况吗？