完成提交后如何获得 "last-changed-revision"
How can I get "last-changed-revision" after having done a commit
我想要一种方法来获取当前工作副本中的最新更改版本。我试过这样做：
svn info --show-item last-changed-revision
这在大多数情况下都有效，但如果我提交，它就不会。例如：
$ svn info --show-item last-changed-revision
169680
$ svn add test.txt
A test.txt
$ svn commit -m "test change"
Adding test.txt
Transmitting file data .done
Committing transaction...
Committed revision 170547.
$ svn info --show-item last-changed-revision
169680
如您所见，它仍然是 return提交后的最后修订版。如果我更新我的工作副本，它将（大部分）工作：
$ svn update
Updating '.':
At revision 170547.
$ svn info --show-item last-changed-revision
170547
但是，这会得到自我提交以来其他人提交的任何更改，这是我宁愿不必承担的风险。
是否有另一种方法可以让我的本地工作区知道我提交的修订，而无需实际获取最新版本？
用例是一个构建工具，我们希望能够在修改后命名构建，但我们也在构建过程中向分支提交版本更新，这就是我们通常不这样做的原因' 从 svn info 调用中获得正确的修订。
编辑： 在收到 Richard Smith 的建议后，我尝试在该行的末尾添加一个 *（并且还尝试了一个 .）。
$ svn commit -m "test change 2"
Sending test.txt
Transmitting file data .done
Committing transaction...
Committed revision 170555.
$ svn info --show-item last-changed-revision *
169680 android
169680 AssetBundles
170555 test.txt
169680 unity
...
$ svn info --show-item last-changed-revision .
170547
$ svn update
Updating '.':
At revision 170555.
$ svn info --show-item last-changed-revision .
170555
如您所见，甚至在 update 之前更新的文件 ("test.txt") 的修订实际上是正确的，但顶层目录的修订不是。这对我来说似乎是 "incorrect"，因为顶层目录包含编辑过的文件，所以它是最近包含的更改，而且因为它 确实 在更新后的目录。
EDIT 2: 我考虑过使用 svn log 代替，认为这显然会包含我刚刚所做的提交，但情况似乎并非如此，或者：
$ svn commit -m "Test 5"
Sending test.txt
Transmitting file data .done
Committing transaction...
Committed revision 170617.
$ svn info --show-item last-changed-revision
170566
$ svn log -l 1
------------------------------------------------------------------------
r170566 | svend.hansen | 2018-11-13 15:06:08 +0100 (Tue, 13 Nov 2018) | 1 line
$ svn log -l 1 test.txt
------------------------------------------------------------------------
r170617 | svend.hansen | 2018-11-14 10:10:12 +0100 (Wed, 14 Nov 2018) | 1 line
$ svn info --show-item last-changed-revision test.txt
170617
所以即使是日志似乎也不return 与工作副本的实际状态相匹配的东西。这一定是 subversion 中的错误，对吧？我想不出任何好的理由让日志不包含实际在工作副本中的更改？
TLDR： 您可以使用此命令获取本地最后可用的更改版本：
svnversion -c
这里有一些关于 SVN 为何以这种方式工作的更多想法，以及我们的解决方案，即不只是直接使用此修订版：
实际上，我可以想到日志不包含最后一次提交的原因：SVN 将允许您向存储库提交更改，即使其中有更改他们本地没有的存储库，只要受这些更改影响的文件不与受您影响的文件重叠。这意味着您可以在没有修订版 8 和 9 的情况下提交修订版 10。因此，当请求整个目录的日志时，它不能显示 10，因为它会丢失 8 和 9。但是，它 can 说它在请求特定文件的最新修订时得到 10，因为如果它们也影响了文件，它不允许你在没有得到 8 和 9 的情况下提交 10，因此他们不会仅包含在该文件的日志中。
我想这种工作方式源于 SVN 在存储库中没有项目，只有很多文件夹，您可以检出任何子文件夹并对其进行更改，而不管文件夹是什么包含它。
这就是我们决定的工作方式：
$ echo test6 > test.txt
$ svn commit -m "Test 6"
Sending test.txt
Transmitting file data .done
Committing transaction...
Committed revision 170633.
$ svnversion -c
20414:170633
$ svn update -r 170633
Updating '.':
At revision 170633.
这样我们都能获得最新更改的修订版，并且我们确保工作副本的状态在构建之前是在 SVN 中表示的状态。
我想要一种方法来获取当前工作副本中的最新更改版本。我试过这样做：
svn info --show-item last-changed-revision
这在大多数情况下都有效，但如果我提交，它就不会。例如：
$ svn info --show-item last-changed-revision
169680
$ svn add test.txt
A test.txt
$ svn commit -m "test change"
Adding test.txt
Transmitting file data .done
Committing transaction...
Committed revision 170547.
$ svn info --show-item last-changed-revision
169680
如您所见，它仍然是 return提交后的最后修订版。如果我更新我的工作副本，它将（大部分）工作：
$ svn update
Updating '.':
At revision 170547.
$ svn info --show-item last-changed-revision
170547
但是，这会得到自我提交以来其他人提交的任何更改，这是我宁愿不必承担的风险。
是否有另一种方法可以让我的本地工作区知道我提交的修订，而无需实际获取最新版本？
用例是一个构建工具，我们希望能够在修改后命名构建，但我们也在构建过程中向分支提交版本更新，这就是我们通常不这样做的原因' 从 svn info 调用中获得正确的修订。
编辑： 在收到 Richard Smith 的建议后，我尝试在该行的末尾添加一个 *（并且还尝试了一个 .）。
$ svn commit -m "test change 2"
Sending test.txt
Transmitting file data .done
Committing transaction...
Committed revision 170555.
$ svn info --show-item last-changed-revision *
169680 android
169680 AssetBundles
170555 test.txt
169680 unity
...
$ svn info --show-item last-changed-revision .
170547
$ svn update
Updating '.':
At revision 170555.
$ svn info --show-item last-changed-revision .
170555
如您所见，甚至在 update 之前更新的文件 ("test.txt") 的修订实际上是正确的，但顶层目录的修订不是。这对我来说似乎是 "incorrect"，因为顶层目录包含编辑过的文件，所以它是最近包含的更改，而且因为它 确实 在更新后的目录。
EDIT 2: 我考虑过使用 svn log 代替，认为这显然会包含我刚刚所做的提交，但情况似乎并非如此，或者：
$ svn commit -m "Test 5"
Sending test.txt
Transmitting file data .done
Committing transaction...
Committed revision 170617.
$ svn info --show-item last-changed-revision
170566
$ svn log -l 1
------------------------------------------------------------------------
r170566 | svend.hansen | 2018-11-13 15:06:08 +0100 (Tue, 13 Nov 2018) | 1 line
$ svn log -l 1 test.txt
------------------------------------------------------------------------
r170617 | svend.hansen | 2018-11-14 10:10:12 +0100 (Wed, 14 Nov 2018) | 1 line
$ svn info --show-item last-changed-revision test.txt
170617
所以即使是日志似乎也不return 与工作副本的实际状态相匹配的东西。这一定是 subversion 中的错误，对吧？我想不出任何好的理由让日志不包含实际在工作副本中的更改？
TLDR： 您可以使用此命令获取本地最后可用的更改版本：
svnversion -c
这里有一些关于 SVN 为何以这种方式工作的更多想法，以及我们的解决方案，即不只是直接使用此修订版：
实际上，我可以想到日志不包含最后一次提交的原因：SVN 将允许您向存储库提交更改，即使其中有更改他们本地没有的存储库，只要受这些更改影响的文件不与受您影响的文件重叠。这意味着您可以在没有修订版 8 和 9 的情况下提交修订版 10。因此，当请求整个目录的日志时，它不能显示 10，因为它会丢失 8 和 9。但是，它 can 说它在请求特定文件的最新修订时得到 10，因为如果它们也影响了文件，它不允许你在没有得到 8 和 9 的情况下提交 10，因此他们不会仅包含在该文件的日志中。
我想这种工作方式源于 SVN 在存储库中没有项目，只有很多文件夹，您可以检出任何子文件夹并对其进行更改，而不管文件夹是什么包含它。
这就是我们决定的工作方式：
$ echo test6 > test.txt
$ svn commit -m "Test 6"
Sending test.txt
Transmitting file data .done
Committing transaction...
Committed revision 170633.
$ svnversion -c
20414:170633
$ svn update -r 170633
Updating '.':
At revision 170633.
这样我们都能获得最新更改的修订版，并且我们确保工作副本的状态在构建之前是在 SVN 中表示的状态。