如何使用 TortoiseSvn 找到更改代码行的修订版本?

发布于 2024-08-09 05:25:01 字数 90 浏览 2 评论 0原文

我有一行代码似乎已注释。基本上我想找到的是更改代码中这一行的修订版。

那么,是否可以在TortoiseSvn Log中看到与特定关键字相关的代码变化?

I have one line of code which seems commented. Basically the thing I want to find is the revision that changed this line in the code.

So, is it possible to see changes in code related to a specific keyword in TortoiseSvn Log?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

夜无邪 2024-08-16 05:25:02

您想要做的是对该源文件执行 Blame ,它将向您显示修订更改了每一行代码。

我不知道有任何命令能够为您提供给定代码行的所有修订...您可以做的是在单个文件上显示日志,然后查看发生的每个修订随着时间的推移。

What you want to do is do a Blame on that source file and it will show you the revisions that changed each of the lines of code.

I'm not aware of any command that would be able to give you all revisions for a given line of code...what you can do is do a show log on a single file and then look at each of the revisions that took place over time.

面如桃花 2024-08-16 05:25:02

梅佐伊德的责备听起来很正确。顺便说一句,我想分享一个命令行 svn 用户可能会觉得有用的技术。 (这是关于 svnblame 的,但我使用“annotate”同义词,或“svn ann”,因为“blame”听起来有点刺耳!)

好的,所以你有一行你感兴趣的行,它有一个独特的字符串在它的“独特的字符串”上。您想要在首次引入该行时阅读提交消息,但它可能已被编辑了几次。因此,您继续执行此操作:

# svn ann that.file | grep distinctiveString
2345     yada yada distinctiveString blah blah

查看 svn 的 TRAC Web 界面,显示 r2345 只是更改了该行的缩进,而不是引入该行的修订版。因此,接下来您使用 -R 标志(或 -r,do svn help ann 来确保)指定比您在上一步中找到的修订版小一个的修订版:

# svn ann -R 2344 that.file|grep distinctiveString
2211  yada yada distinctiveString blah blah

冲洗并重复,直到找到原始版本。

您可以在每个步骤中省略 TRAC 查找,只需重复直到不再看到该行,然后获取倒数第二次迭代的结果即可。

好吧,这有点费力,但如果您真的想知道是谁介绍了这句话,它就可以完成这项工作。如果原始提交消息解释了一段看似可以删除的晦涩代码的意图,那么它可以节省您的时间。

Mezoid's Blame sounds correct. As an aside, I'd like to share a technique that commandline svn users might find useful. (It's about svn blame, but I use the "annotate" synonym, or "svn ann", because "blame" sounds a bit harsh!)

OK, so you have a line you're interested in, and it has a distinctive string on it "distinctiveString". You want to read the commit message when the line was first introduced, but it may have been edited a few times. So, you go ahead and do this:

# svn ann that.file | grep distinctiveString
2345     yada yada distinctiveString blah blah

A look at your TRAC web interface for svn shows that r2345 simply changed the indentation of the line, it wasn't the revision at which the line was introduced. So next you use the -R flag (or -r, do svn help ann to make sure) to specify the revision one less than the revision you found in the previous step:

# svn ann -R 2344 that.file|grep distinctiveString
2211  yada yada distinctiveString blah blah

Rinse and repeat until you find the original.

You can omit the TRAC lookup at each step by simply repeating until you don't see the line any more, and taking the result of the penultimate iteration.

OK, it's a bit laborious, but if you really want to know who introduced that line it will do the job. It can save you time if the original commit message explains the intent of an obscure piece of code that otherwise looks like it could be removed.

轮廓§ 2024-08-16 05:25:02

您可以右键单击存储库中的文件并选择 TortoiseSVN->Show Log 以获取该文件受影响的修订版本。在逐行的基础上,我不知道有什么办法。

You can right-click on a file in your repo and select TortoiseSVN->Show Log to get the revisions this file was affected by. On a line by line basis, there is no way I know of.

知足的幸福 2024-08-16 05:25:02

我一直在寻找相同的功能,但最终来到这里,我不再继续寻找。

但这是我正在使用的一种技术,它可能对其他人有帮助:

  1. 识别感兴趣的线。最后调用它:第 123 行。
  2. 使用 Tortoise 来“显示文件的日志”。
  3. 考虑日志中的完整列表。
  4. 如果您不知道什么时候会发生,请使用“快速排序思维方式”,我的意思是,转到列表中间的修订版本,右键单击并“与工作副本进行比较”。
  5. 如果第 123 行存在(相同的内容,但可能有不同的行号),那么您现在应该只考虑列表的下半部分,否则您现在应该只考虑列表的上半部分。返回到步骤 4。

做起来比解释起来容易。由于本文是针对开发人员的,因此我知道无需添加更多详细信息:)

I was looking for the same feature and i end up here and i quit looking any further.

But here is a technique i am using and it may help anyone else:

  1. Identify the line of interest. Last call it: line 123.
  2. Use to Tortoise to "show log" of the file.
  3. Consider the full list in the log.
  4. If you have no idea when it could have happened, use the "quick sort mindset", i mean, go to the revision in middle of the list, right click and "compare with working copy".
  5. If the line 123 exists (same content, but probably a different line number), then you should now consider only the bottom half of the list, else you should now consider only the top half of the list. Go back to step 4.

It is easier to do than to explain. Since this text is target for developers, I understand there is no need to add more details :)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文