如何调试旧版本软件？
注意：目前使用 Perforce 作为 CM 工具。
我目前做了几个软件的调试版本[仅调试文件（.pdb）和二进制文件（.dll 和 .exe）]。 在每个版本中，我都会将用于生成二进制文件的所有文件检查到我们的 CM 工具（基线）中。 然后我签出文件并继续进行更改。 目前，如果其中一个版本存在问题，需要我们对其进行调试，我就必须将代码恢复到所使用的版本。
我的问题是，我应该如何轻松调试旧版本？ 如果我从刚刚所做的基线创建一个分支，那么我可以轻松地构建以前的版本进行调试，但是比这更早的版本又如何呢？ 我不想每次做基线时都分支（很确定我不想这样做）。
我知道使用 VHDL，您可以使用测试点创建构建，并使用 Xilinx 工具来调试 VHDL 的任何构建版本。 我们是否可以在 VS 中以类似的方式执行此操作（也许使用 .pdb 文件和一些外部工具）？
您如何进行基线修订以便可以轻松调试旧版本？
Note: Currently using Perforce as a CM tool.
I currently do several debug releases of software [only debug files (.pdb) and binaries (.dll and .exe)]. At every release, I check the all the files used to generate the binaries into our CM tool (baseline). Then I checkout the files and continue making changes. Currently, if there was an issue with one of the releases such that we needed to debug it, I would have to revert the code back to the version used.
My question is, how should I go about easily debugging old versions? If I create a branch from the baseline I just did, then I could easily just build the previous version for debugging, but what about further back than that? I don’t want to branch every time I do a baseline (pretty sure I don’t want to do that).
I know with VHDL you can create builds with test points and use the Xilinx tools to debug any built version of VHDL. Is there a similar way we can do this in VS (maybe using the .pdb files and some external tools)?
How do you go about baselining revisions so that you can easily debug old version?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Eric Sinc 有一篇精彩的源代码控制指南，涵盖了这个主题（以及更多内容）。
我强烈建议您阅读它，因为这个人知道他的东西。
您最感兴趣的是第 6 章：历史 和 第 7 章：分支。
当我学习源代码控制和软件发布策略时，这些东西确实对我很有帮助。
Eric Sinc has a fantasic Source Control HOWTO that covers this topic (and much more).
I would highly recommend reading it because this guy knows his stuff.
You'd be most interested in Chapter 6: History and Chapter 7: Branches.
This stuff really helped me when I was learning about source control and software release strategies.
使用 p4，您不必创建分支来“回到过去”。 您所要做的就是同步到适当的标签或更改号码。 例如，如果您要重新创建 ProductX 版本 1.1，并且 p4 中的最后一次更改是更改编号 2000，您可以执行以下操作：
或者如果使用了标签，例如“Release1.1”，您可以执行以下操作：
或如果您无法弄清楚这些，您甚至可以尝试在特定日期同步。 例如：
有关 p4 中有关文件修订的更多信息，请尝试以下操作：
With p4 you don't have to create a branch to go "back in time". All you have to do is sync to the appropriate tag or change number. For instance, if you were to recreate version 1.1 of ProductX, and the last change in p4 was change number 2000, you can do the following:
or if a tag was used, such as "Release1.1" you can do this:
or if you couldn't figure those out, you could even try to sync at a certain date. Such as:
For more information in p4 concerning file revisions, try this:
警告 - 对我和 perforce 来说已经有一段时间了：
对于 perforce，我可能会继续“标记”每个版本（在 perforce 中，标记文件会创建一个标签）
然后您可以签出标记来调试它。 如果您需要进行更改并针对旧版本推出“修补程序”，您可以从该标记而不是从 HEAD 创建分支。
标记非常简单，“p4 tag -l release2.0 //depot/bch/...”
从标记分支并不太难，您需要创建一个新分支，然后从源标签集成：“p4集成-b [分支名称] -s //depot/bch/[电子邮件受保护]”
请注意，您也可以标记代码的以前（历史）版本，或者也可以从以前的提交创建分支。
warning - been a while for me and perforce:
For perforce, I'd probably go ahead and "Tag" each release (in perforce, tagging files creates a label)
Then you can checkout a tag to debug it. If you need to make changes and push out a "hotfix" against that old version, you can create a branch from that tag rather than from the HEAD.
Tagging is pretty simple, "p4 tag -l release2.0 //depot/bch/..."
Branching from a tag isn't too hard, you need to create a new branch then integrate from the source label: "p4 integrate -b [branchname] -s //depot/bch/[email protected]"
Note that you can tag previous (historical) versions of the code as well, or create branches from previous commits too.