On Tue, 7 Nov 2023 19:34:34 +0100, Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote:
> >svn blame accepts an -r N:M so if you know the revisions that occurred in >the time period of interest (maybe also works with the date range arguments >already suggested by Nathan) you should be able to limit the revision >numbers. Didn't try that... >But since you use TortoiseSVN I might suggest that you look at Tortoises >graphical Blame. It looks much like the command line client in that you get >the revision number each line was changed but you can right click a >revision number and blame previous revision which will give the previous >time that line was changed. I find this helps a lot to figure out past >refactorings. > Well I have actually been using the command line for this "research" and with log I could list all 106 checkins to the file over the years. But I failed to find the place where the code I am looking for was checked in, instead I discovered an old working copy (from CVS) on my disk where the file I was looking at actually *had* the changes I was trying to find... But looking in SVN both sides of the timestamp of the file failed to get any commit with the changed code. So the conclusion is that that particular code section which should have fixed the bug back in 2015 was actually not checked in to CVS and hence did not reach SVN a couple of years later. So the binary in that working copy worked as it should whereas all following compiles (that were part of the transfer to Delphi XE5 vis SVN) did not since they were based on fresh checkouts.... Looks like an oversight at the time... -- Bo Berglund Developer in Sweden
