有没有一个好的SVN工具可以轻松查看过去的修订版本？
源头控制很棒。一个很好的功能是，我知道如果出现问题，我可以返回到以前的修订版本。
然而，我仍然发现自己不愿意删除一大批不再需要的代码，但我将来可能想使用其中的一部分。它在当前的代码库中确实没有任何意义。但是，我不喜欢删除它，因为我没有一种简单的方法来浏览我的修订历史记录并找到它。我经常会剪切+粘贴它，并将其放入具有“unused”和“tmp”等描述性名称的文件中，它们会在那里放置一段时间。
如果我有一个很好的方法来浏览存储库历史记录/搜索过去的代码，这个问题就可以解决。是否有任何 GUI 可以让我执行此操作，或者我可以使用任何易于使用的流程？有没有办法用 TortoiseSVN 来做到这一点？现在我知道采取的唯一方法是检查不同的修订号，看看我想要的文件是否在那里，但这太耗时了。
Source control is great. One of the nice features is that I know that I can go back to previous revisions in case something messes up.
However, I still find myself loathe to delete a large batch of code that is no longer necessary, but that I might want to use parts of in the future. It really has no business in the current code base. However, I don't like to delete it, because I don't have an easy way to trawl through my revision history and find it. I'll often cut + paste it and put it in files with such descriptive names as "unused" and "tmp", and they'll sit there for a while.
This problem would be solved if I had a great way to browse through the repository history / search for code from the past. Is there any GUI that lets me do this, or any easy to use process I can use? Is there any way to do this with TortoiseSVN? Right now the only approach I'd know to take is to checkout different revision numbers to see if the file I want is there, and that just takes way too lang.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以通过查看 Tortoise SVN 中的更改来做到这一点...但是...
我个人更喜欢 Mercurial 。
当您在小组中工作时，您可以根据需要随时在本地提交，然后当您想尝试提交小组解决方案时，您可以合并所有内容。这样，无论合并期间发生什么，都不会丢失数据，因为每个人的硬盘上都有备份存储库，并且合并前的版本在组存储库中可用。这还意味着您可以在每次进行更改时提交，无论它是否有效，因为在您将其推送到组存储库之前没有其他人看到它。我喜欢在我的提交中添加相当长的注释，因为这意味着我绝对不必搜索正确的版本。
它与 Tortoise（我在工作中使用的）有点不同，但就我而言绝对更好。
You can do that by viewing changes in Tortoise SVN...however...
I personally prefer Mercurial.
When you are working in a group, you are able to commit locally as often as you please, then when you want to try to commit to the group solution you can merge everything. This way, no matter what happens during a merge, no data is lost because everyone has back up repositories on their hard drives, and the pre-merge version is available on the group repository. It also means that you can commit every time you make a change, regardless of whether or not it works, because no one else sees it until you push it to the group repo. I like to add rather lengthy comments to my commits, because it means I absolutely don't have to search for the right version.
It's a bit different than Tortoise (which I use at work), but definitely better as far as I am concerned.
我喜欢做的是添加一个标签：说“Codebase_before_removing_such_and_such_function”。然后您可以进入 TortoiseSVN 中的存储库浏览器，浏览到该标签，并深入其中查找旧文件。单击该文件并选择“打开”即可查看该文件中的代码。
您还可以通过更改存储库浏览器以指向特定修订版本而不是指向 HEAD（然后再次浏览到所需的特定文件并打开它）来执行相同的操作，但标记更容易，因为您可以为标记赋予有意义的标记名称。
What I like to do is add a tag: say "Codebase_before_removing_such_and_such_function". Then you can go into the Repository Browser in TortoiseSVN, browser to that tag, and dig into it to find the old file. Click on that file and select "open" to just see the code in that file.
You can also do the same by changing the Repository Browser to point to a particular revision rather than pointing to HEAD (and, again, then browsing to the particular file you want and opening it) but it's easier to tag because you can give tags meaningful names.
您可以使用 svn 命令行，以及 -v （详细，显示更改的路径）和 --xml 选项，并将结果通过管道传输到 XMLStarlet。这将允许您按已删除的操作进行过滤，并显示文件被删除的修订（然后您可以通过 grep 管道来获取您要查找的文件）。
示例：
示例输出：
显然，使用 svn log，您可以将其限制为修订范围 (-r M:N) 或日期范围 (-r {date1}:{date2})，或最后 N 个修订 (-l C) 。
唯一的缺点是误报，因为 SVN 移动实际上是复制+删除。
一旦您知道删除它的修订版，您就可以使用 svn cat 或 svn export 来查看该文件：
由于 deprecated.h 在 r103 中被删除，我告诉 svn 获取 deprecated.h 的路径，因为它存在于 r102 中（删除之前）。
You can use svn command line, with the -v (verbose, showing changed paths) and --xml options, and pipe the result into XMLStarlet. This will allow you to filter by the deleted action, and show you revisions where files were deleted (which you can then pipe through grep to get the file you were looking for).
Example:
Sample Output:
Obviously, with svn log you can constrain that to a range of revisions (-r M:N), or range of dates (-r {date1}:{date2}), or last N revisions (-l C) .
The only downside is false positives due to the fact that SVN moves are really copy+delete.
Once you know the revision in which it was deleted, you can then use svn cat or svn export to look at the file:
Since deprecated.h was deleted in r103, I told svn to get the path to deprecated.h as it existed in r102 (prior to deletion).