TFS - 执行签出 +如果正在签入另一个文件，则签入某个文件
我有一些 XSD 文件，我使用 MS 的 XSD.exe 实用程序生成类。
我使用预构建来签出生成的代码类文件，并使用帖子来签入。
由于有多个开发人员在同一个项目上工作，并且每次决定重建时都会发生这种情况，因此我们不断遇到冲突不是真正的冲突（只是由略有不同的 xsd 工具版本引起的，该版本包含在生成的 cs 文件标头中的某处）。
为了解决这个问题，我想首先将 XSD 的内容与源服务器进行比较，然后才执行签出 + 签入操作。
有没有办法使用 TFS 来做到这一点？
注意：我尝试在 tf.exe 中使用 diff 命令，但它没有返回退出代码，我可以用它来了解比较结果。
任何帮助将不胜感激...
I have some XSD's files which I generate classes for using the XSD.exe utility from MS.
I use the pre-build to check-out the generated code classes file and the post to check back in.
Since there are several developers working on the same project and this is happening every time each decides to rebuild we keep getting conflicts on it which is not real conflicts (simply caused by a slightly different xsd tool version which is included somewhere in the header of the generated cs file).
To resolve this I wanted to first compare the XSD's content with the source server and only then perform the operation of the check-out + check-in.
Is there a way to do this using TFS?
Note: I tried using the diff command in the tf.exe but it does not return an exit code which i can use to know the result of the compare.
Any help would be much appreciated...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以使用 tf.exe 并对 XSD 文件执行 get 命令，如果它返回“所有文件都是最新的”，您就知道您不必执行签出/生成/签入处理
You can use tf.exe and execute a get command for the XSD files, and if it returns "All files are up to date" you know that you don't have to do the check out / gen / check in processing
我的建议是解决问题的原因而不是症状。
开发时，您应该尝试让开发人员和构建服务器都使用完全相同的工具和源代码集运行，这样您就知道都会获得一致的结果。您无法保证两个不同版本的工具的输出始终相同/兼容。简单的版本号不匹配是没有问题的，但是如果您生成的最终程序根据构建者的不同而存在细微的差异，该怎么办？ Fred 可能永远无法重复并修复客户所抱怨的错误。或者您可能认为您已经修补了主要的 ATL 安全漏洞，直到有一天您意识到您一直在从一台您懒得修补的构建服务器发送产品。
有一个标准化的安装过程（每个人都仔细遵循的“如何安装”文档，一个包含正确的 DVD 集的盒子，和/或一个包含要安装的安装程序集的网络文件夹或源代码控制文件夹）是一件非常简单的事情。使用的、要链接的库等）
My advice would be to fix the cause of the problem rather than the symptoms.
When developing, you should try to have your developers and your build server all running with exactly the same set of tools and source code, so you know you'll all get consistent results. You cannot guarantee that the output from two different versions of a tool will always be identical/compatible. Simple mismatching version numbers are no problem, but what if the final program you generate has subtle differences depending on who built it? Fred may never be able to repeat and fix the bug that your customer is complaining of. Or you may think you've patched that major ATL security vulnerability until one day you realise you've been shipping product from a build server you didn't bother to patch.
It's a pretty simple matter to have a standardised install process (a "how to install" document that everyone follows carefully, a box containing the correct set of DVDs, and/or a network folder or source controlled folder containing the set of installers to be used, libraries to be linked to, etc)