Svn 1.7 - 当工作副本具有不存在的修订版本时如何将工作副本切换到重新定位的存储库
svn repo http://svn/repoA/path1/ 中有一个 svn 项目。将此称为原始存储库。
这已复制到 http://svn/repoA/path2 。将此称为新存储库。
我们一台机器上的本地工作副本（从原始存储库中签出）在该副本发生后进行了更新。
然后原始仓库被删除。
我们现在希望将工作副本重新集成到新的存储库中。
svn switch 适合于此。在项目基目录中运行：
svn switch http://svn/repoA/path2
但是，switch 会抱怨，因为该项目的修订号在新存储库中不存在。
在 svn 1.6 中，我会在项目基目录下递归地更改 .svn/entries 中的修订号，它以纯文本形式存储在该目录中。
在 svn 1.7 中，此类信息似乎不透明地存储（以某种方式编码）到 .svn/wc.db 或其他新文件中。
我的问题是：如何强制工作副本认为它是复制的修订历史记录的现有修订，以便我可以将其切换到克隆的存储库文件夹，然后更新它？
There was an svn project in svn repo http://svn/repoA/path1/ . Call this original repo.
This was copied to http://svn/repoA/path2 . Call this new repo.
A local working copy on one of our machines, checked out from original repo, was updated after this copy occurred.
Then original repo was deleted.
We now wish to reintegrate the working copy into new repo.
svn switch is suitable for this. Running inside the project base directory:
svn switch http://svn/repoA/path2
However, switch complains because the project has a revision number which does not exist in new repo.
In svn 1.6 I would have changed the revision number in .svn/entries recursively under the project base dir, where it is stored as plaintext.
In svn 1.7 such information seems to be stored opaquely (encoded in some way) into .svn/wc.db or other new files.
My question is: how can I force the working copy to think it's an existing revision on the copied revision history so that I can switch it to the cloned repo folder and thereafter update it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您知道您不应该触摸这些
.svn目录。我敢打赌，即使有一个标签清楚地写着警告：内部没有用户可维修的部件，您也会打开电子设备的背面。除非需要触电猝死，否则请勿打开。。是的，我也是。
您仍然可以在旧工作目录上执行
svn status来查找更改的文件，然后将它们复制到新工作目录。即使旧存储库不存在，svn status也将起作用。或者，您可以在另一个目录中签出新的工作副本，从旧的工作副本中删除所有旧的
.svn目录，然后将所有这些文件复制到新的工作目录。然后，您可以执行svn status来查找更改的内容，并修复这些问题。You know you were not suppose to touch those
.svndirectories. I bet you also open the back of electronic appliances even though there's a label that clearly says Warning: No user serviceable parts inside. Do not open unless sudden death by electrocution is desired.Yes, I do too.
You can still do a
svn statuson the old working directory to find your changed files, and then copy those over to the new working directory. Ansvn statuswill work even though the old repository doesn't exist.Or, you can checkout a new working copy in another directory, delete all the old
.svndirectories from the old working copy, and then just copy all of those files over to the new working directory. You can then do ansvn statusto find what changed, and fix those issues.SVN 开关通常会删除新存储库中不存在的文件并添加新存储库中存在的文件。但是，就您的情况而言，没有可以切换到的等效修订版本。因此，
svn switch确实不是适合这项工作的工具。查看 svn import 来从签出的工作存储库重建旧的“原始”服务器存储库。
如果您确实想按照以前的方式进行操作，请记住 SVN 现在使用更少的 .svn 目录。查看结帐根目录中是否有重要的 .svn 目录。另请记住，大多数信息不再由文本文件构成，而是在 SQLLite 二进制数据库中。可以使用 SQLLite 兼容的数据库客户端修改数据库条目；然而，这是非常不推荐的。与处理旧文本文件相比，将工作存储库变成一堆粘液的风险要大得多。
如果目的是删除大量修订历史记录，但希望修订版本号匹配，则需要重建 repo1，使其丢失不需要的历史记录，但修订版本号匹配。为此，
或者在我的假示例中，rev 8323 是要保留的最后一点历史记录，当前的 rev 是 9929。
A SVN switch would normally remove files that don't exist in the new repo and add files that do exist in the new repo. However, in your case there is no equivalent revision to switch to. As such,
svn switchreally isn't the right tool for this job.Look into
svn importto rebuild the old "original" server repo from the checked out working repo.In the event that you REALLY want to do it they way you formerly did, keep in mind that SVN now uses fewer .svn directories. Look to the root of your checkout for the one .svn directory that matters. Also keep in mind that most of the information is no longer structured with text files, but instead in SQLLite binary databases. Modifying the database entries with a SQLLite compatible database client is possible; however, it is very unrecommended. You run a much greater risk of turning your working repository into a pile of goo than you did with the old text files.
If the intent was to remove a lot of revision history, but you want the reivsion number to match, you need to rebuild repo1 such that it is missing the undesirable history, but the revision numbers match. To do so,
Or in my fake example, rev 8323 is the last bit of history to be kept, and the current rev is 9929.