3

我只是在使用 TFS 一段时间后回到颠覆，一般来说我很退出:)

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

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

那么这个混合修订的东西是最近添加的还是只是我？

4

5 回答 5

3

是你，因为一直都是这样 ;-)

如果您尝试提交的任何项目已过时，您的提交将失败，并且存储库有一个“通用”修订号，但只要您要提交的所有内容都是最新的，你可以提交。当然，这并不意味着它是最佳实践。

请记住，svn 不仅用于软件开发。总的来说，这种能力可能很不错。

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

于 2009-08-15T06:49:04.053 回答
1

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

如果你遵循这个规则，你可以睡得更好。

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

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

于 2009-08-14T23:38:45.543 回答
1

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

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

于 2009-08-15T00:05:23.227 回答
0

感谢您清除这些家伙。考虑一下，我想我的建议无论如何都会在客户端实现。我完全明白，确保一切都能编译仍然取决于开发人员。实际上，这并不是一个大问题，但是有好几次，开发人员在没有首先更新他的工作副本的情况下提交了工作，从而导致头部修订失败。

在旁注中，这个来自 Tortoise 的例子怎么样：http: //tortoisesvn.net/node/13

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

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

于 2009-08-17T06:49:46.517 回答
0

不，您不能提交 svn 过期文件。阅读： http ://subversion.tigris.org/faq.html#wc-out-of-date

于 2009-08-15T06:58:10.073 回答