Subversion 在合并时忽略对单个文件的本地更改
Subversion ignore local changes to single file on merge
是否可以在合并另一个分支时忽略对单个本地文件的更改？
我有一个批处理文件，它对单个文件进行更改，然后在 TortoiseSVN 中启动提交对话框。这会导致每次合并时与该文件发生冲突，但在每种情况下，我都想要该文件的服务器版本，同时不干扰所有其他文件的正常冲突过程。
据我所知，在任何 google 搜索或文档中我都没有发现任何有希望的东西。我可能不是在搜索正确的术语，或者只是在做一些非常不常见的事情。
我正在处理的项目的要求是将当前工作副本的修订号签出显示在页脚中。我发现执行此操作的最简单方法是使用包含要替换关键字的文件 version.txt。我们使用仅更新此文件的批处理文件提交，然后启动 TortoiseSVN 对话框，这样我们就可以像以前一样使用 GUI 提交。本地工作副本和开发服务器是这样工作的。生产使用一个部署脚本来清理一些东西，这样我们就可以导出特定的标记版本。
我不确定你的用例是什么。 user/computer 特定的文件不应该是您的 SVN 存储库的一部分。也许您可以尝试参数化您的批处理文件？
关于合并：原则上，应该始终在 clean 工作目录中合并。
如果您真的必须继续当前的工作方式，可以在合并后使用 svn resolve 从命令行修复您的工作目录（参见 svn help resolve）：
svn resolve --accept theirs-full <your file>
batch file that makes changes to a single file and then launches the commit dialog in TortoiseSVN
坏主意 (tm) 共同点。 Bat-file 也可以使用 SVN
的 CLI 静默提交
I want the server version of that one file
糟糕的不洁术语。 所有个在所有节点（分支）中提交的文件是"server version"。您必须编写 "my" 或 "another" 版本的更改文件必须在合并后存储在 "another" 分支的 "my" 中才能获得完整答案。
简短的答案草稿现在将是：
- 在合并整个树之前将单个（您更改的）文件与另一个分支的文件合并，使用
--accept 选项和所需的 ARG 以获得请求的结果
- 合并完整分支
我们已经确定您的功能要求是将工作副本的当前修订版合并到在那里完成的任何构建中（在某些文档的页脚中）。
您当前的方法
您有一个文件 version.txt，其中包含 $Revision$ 关键字，Subversion（如果启用）将按照 Keyword Substitution1 下的手册中的描述进行替换 （我的重点）:
This … describes the … revision in which this file changed …, and looks … like $Revision: 144 $.
您在每次提交前用脚本更新version.txt（以某种方式或其他方式），以确保此文件的最后修订版是工作副本所基于的分支的修订版。从 version.txt 导出修订号的过程可能对您用来确保最新修订的任意更改不敏感。
你的问题
你观察到的缺点是，当你从一个分支合并到另一个分支时，在两个分支中对 version.txt 所做的任意更改意味着 version.txt 总是冲突的。因此，在这样的合并之后，您首先需要解决冲突（您的提交脚本将像往常一样自动应用新的任意更改）。
因此，您要求一种方法来忽略本地更改并自动使用要合并的存储库中的 version.txt。
建议的 Subversion 方法
你对 version.txt 的任意更改是你的解决方案，即“$GlobalRev$ 在哪里？”下的框中描述的问题。在手册的 the same page1 上：
New users are often confused by … $Rev$ … Since the repository has a global… revision number…, many people assume that … this … is reflected by … $Rev$ …. … frustration often remains — without … a … keyword …, how can you … get the global revision number …?
… Subversion ships with a tool called svnversion … for … this purpose. It crawls your working copy and generates as output the revision(s) it finds. You can use this … to embed that revision … into your files. For more information …, see svnversion Reference1.
svnversion 的输出显示了工作副本中的修订范围以及它是否混合、修改 and/or 稀疏，ee.g。 4168 或 4123:4168MSP.
其他方法和观察结果
- 您可以继续使用当前的方法，并且在合并时使用
svnresolve1--accept theirs-full 自动解决冲突<WC-path>。
- 您可能会发现先合并
version.txt更方便，合并svn merge--accept theirs-full1</code><em><code><Source-URL>/version.txt <WC-path>/version.txt.
- 无论您使用
mine-full theirs-full 还是其他任何东西都无关紧要，因为您只提取修订号并忽略任意更改（只要该过程仍然有效）。
- 您可以转换
svninfo1<WC-path> 的输出。我提到这个是因为这是我过去使用的方法，但你可能会发现 svnversion 更合适。
- 当您构建标签时，您的问题通常不会出现：创建和签出标签将产生一个
version.txt 以及标签的修订号。
- 如果您在多个平台上构建，其中一些平台没有
svn info/svnversion，那么您可以使用例如复制到它们ftp，您可以 • 在复制前生成 svn* 输出， • 使用 $Revision$ 关键字，或者 • 省略该平台上的修订。
脚注
1 请注意，参考的是手册的 1.8 版，截至 2018 年 12 月 27 日仍然是最新版本；如有疑问，请检查 http://www.svnbook.com/.
编辑
2015-06-16 处理非svn平台
2018-12-27 参考手册状态版本
是否可以在合并另一个分支时忽略对单个本地文件的更改？
我有一个批处理文件，它对单个文件进行更改，然后在 TortoiseSVN 中启动提交对话框。这会导致每次合并时与该文件发生冲突，但在每种情况下，我都想要该文件的服务器版本，同时不干扰所有其他文件的正常冲突过程。
据我所知，在任何 google 搜索或文档中我都没有发现任何有希望的东西。我可能不是在搜索正确的术语，或者只是在做一些非常不常见的事情。
我正在处理的项目的要求是将当前工作副本的修订号签出显示在页脚中。我发现执行此操作的最简单方法是使用包含要替换关键字的文件 version.txt。我们使用仅更新此文件的批处理文件提交，然后启动 TortoiseSVN 对话框，这样我们就可以像以前一样使用 GUI 提交。本地工作副本和开发服务器是这样工作的。生产使用一个部署脚本来清理一些东西，这样我们就可以导出特定的标记版本。
我不确定你的用例是什么。 user/computer 特定的文件不应该是您的 SVN 存储库的一部分。也许您可以尝试参数化您的批处理文件？
关于合并：原则上，应该始终在 clean 工作目录中合并。
如果您真的必须继续当前的工作方式，可以在合并后使用 svn resolve 从命令行修复您的工作目录（参见 svn help resolve）：
svn resolve --accept theirs-full <your file>
batch file that makes changes to a single file and then launches the commit dialog in TortoiseSVN
坏主意 (tm) 共同点。 Bat-file 也可以使用 SVN
的 CLI 静默提交I want the server version of that one file
糟糕的不洁术语。 所有个在所有节点（分支）中提交的文件是"server version"。您必须编写 "my" 或 "another" 版本的更改文件必须在合并后存储在 "another" 分支的 "my" 中才能获得完整答案。
简短的答案草稿现在将是：
- 在合并整个树之前将单个（您更改的）文件与另一个分支的文件合并，使用
--accept选项和所需的 ARG 以获得请求的结果 - 合并完整分支
我们已经确定您的功能要求是将工作副本的当前修订版合并到在那里完成的任何构建中（在某些文档的页脚中）。
您当前的方法
您有一个文件 version.txt，其中包含 $Revision$ 关键字，Subversion（如果启用）将按照 Keyword Substitution1 下的手册中的描述进行替换 （我的重点）:
This … describes the … revision in which this file changed …, and looks … like $Revision: 144 $.
您在每次提交前用脚本更新version.txt（以某种方式或其他方式），以确保此文件的最后修订版是工作副本所基于的分支的修订版。从 version.txt 导出修订号的过程可能对您用来确保最新修订的任意更改不敏感。
你的问题
你观察到的缺点是，当你从一个分支合并到另一个分支时，在两个分支中对 version.txt 所做的任意更改意味着 version.txt 总是冲突的。因此，在这样的合并之后，您首先需要解决冲突（您的提交脚本将像往常一样自动应用新的任意更改）。
因此，您要求一种方法来忽略本地更改并自动使用要合并的存储库中的 version.txt。
建议的 Subversion 方法
你对 version.txt 的任意更改是你的解决方案，即“$GlobalRev$ 在哪里？”下的框中描述的问题。在手册的 the same page1 上：
New users are often confused by … $Rev$ … Since the repository has a global… revision number…, many people assume that … this … is reflected by … $Rev$ …. … frustration often remains — without … a … keyword …, how can you … get the global revision number …?
… Subversion ships with a tool called svnversion … for … this purpose. It crawls your working copy and generates as output the revision(s) it finds. You can use this … to embed that revision … into your files. For more information …, see svnversion Reference1.
svnversion 的输出显示了工作副本中的修订范围以及它是否混合、修改 and/or 稀疏，ee.g。 4168 或 4123:4168MSP.
其他方法和观察结果
- 您可以继续使用当前的方法，并且在合并时使用
svnresolve1--accept theirs-full自动解决冲突<WC-path>。- 您可能会发现先合并
version.txt更方便，合并svn merge--accept theirs-full1</code><em><code><Source-URL>/version.txt <WC-path>/version.txt. - 无论您使用
mine-fulltheirs-full还是其他任何东西都无关紧要，因为您只提取修订号并忽略任意更改（只要该过程仍然有效）。
- 您可能会发现先合并
- 您可以转换
svninfo1<WC-path>的输出。我提到这个是因为这是我过去使用的方法，但你可能会发现svnversion更合适。 - 当您构建标签时，您的问题通常不会出现：创建和签出标签将产生一个
version.txt以及标签的修订号。 - 如果您在多个平台上构建，其中一些平台没有
svn info/svnversion，那么您可以使用例如复制到它们ftp，您可以 • 在复制前生成svn*输出， • 使用$Revision$关键字，或者 • 省略该平台上的修订。
脚注
1 请注意，参考的是手册的 1.8 版，截至 2018 年 12 月 27 日仍然是最新版本；如有疑问，请检查 http://www.svnbook.com/.
编辑
2015-06-16 处理非svn平台
2018-12-27 参考手册状态版本