svn update -r {2010-10-17}命令来实现。但是，当遇到外部文件时，它会在不传递-r {2010-10-17}选项的情况下对其进行更新。这导致我们获得了基本代码的正确过去版本，但许多外部文件的最新（不需要的）版本。我希望有人能够在bash和cmd脚本中实现我的常识逻辑（仅限于某些区域的目录类型外部），并且我们将得到这个重复问题的“最终答案”。
你的基本任务是：
svn up你的超级库到过去所需的点（更新到日期/没有时间/不是最好的选择，但可行）svn propget svn:externals -R（-R以便在没有大量cd的情况下检查整个树）. - https://subversion.assembla.com/svn/subversion-trouble-shooting/trunk/lib lib）：相对于第一个字段的最后一个字段cd，这又是相对于根的相对路径，然后svn up到与超级repo执行的相同点：svn update -r {2010-10-17}结果将是混合工作副本，但超级库和外部将处于“过去某个修订版本”的状态。
注意：
构建具有外部目录的本地路径的其他示例（真正嵌套的WC）更为复杂。
对于
>svn propget svn:externals -R
tags\1.0.1 - -r 2 https://subversion.assembla.com/svn/subversion-trouble-shooting/trunk/lib@2 lib
trunk - https://subversion.assembla.com/svn/subversion-trouble-shooting/trunk/lib lib
我的工作副本中外部文件的最终路径将是（相对于工作副本根目录）
tags\1.0.1\lib
trunk\lib
如果有人尝试将已经检出的Subversion存储库更新以使本地文件日期与存储库日期同步，我在此添加答案，因为我想进行FS时间戳比较。
我创建了这个一行命令来完成这个技巧（但在使用之前请阅读下面的行）：
svn info --show-item last-changed-date -R | xargs -I{} -P1000 -n1 sh -c 'x="{}"; set -x; exec touch -d "${x%% *}" "${x#* }"'
注意：-P1000指定xargs应该运行1000个并行的sh和touch来实际进行更新。根据系统负载情况，降低这个值可能是明智的。在一个小型的基于i3的Intel NUC上，使用1000个进程实际上非常完美，使用80-95%的CPU（100%通常意味着CPU超载）。如果不确定，请打开例如htop并测试不同的值，但每次只运行几秒钟，因为它需要从头开始运行。
对于一个存储在USB硬盘上的小型约3GB SVN仓库，这个操作大约需要5分钟。
set +x打开详细执行模式，在执行touch之前使用，这样您就可以观察它的运行情况。如果您想要非详细执行模式，请删除该命令。
我们只在其他项目中包含整个目录：
使用这种布局，svn propget svn:externals -R 返回：
# cd mainprj
# svn propget svn:externals -R
bin - subprj1 svn+ssh://svnserver/svn/subprj1/trunk/bin
subprj2 svn+ssh://svnserver/svn/subprj2/trunk/bin
dat - subprj1 svn+ssh://svnserver/svn/subprj1/trunk/dat
subprj2 svn+ssh://svnserver/svn/subprj2/trunk/dat
你可以按照以下方式更新到一个固定日期：
svn propget svn:externals -R |\
grep -vE '^$' | sed -e "s/^[^-]* - //" |\
while read line; do \
pushd ${line##*/}; \
svn update -r {2019-04-26} ${line%% *}; \
popd; \
done