A widespread tool used by teams of programmers to work on big projects are Version Control Systems (e.g. Git). It allows to clone any version of the repository, create new branches from any existing project version and merge the changes to the main project.
If a new programmer joins a project which currently doesn’t work because of problems somewhere in one of many existing files it may be very time consuming to identify the error source. Sometimes errors are well identifiable (e.g. “syntax error at line …”). But what if they are not (e.g. the application just does not start correctly without giving useful information)?
One of the most helpful git command for supporting the bug search is bisect, which lets the programmer find out what was the last “good” commit. When you get to this point, just use the git command diff to know about what was changed. You can use git blame to know who was the last person who changed the line. Furthermore, git can offer commands to restore a previous versions not only of the whole project but also of individual files with checkout command. It means, you can run the same project but with older versions of one or more particular files. This process is shown below:
A “pagewise” graphical approach model to implement:
This approach is more file-oriented but remains a theoretical model since I could not find any implementation. To get a first view of an unknown project it could be useful to increase the awareness of how the project structure looks like by showing how the code pages are linked with each other through a graphical dependency tree. There exist some tools doing this job (e.g. for PHP codes, you can check this).
Assuming you have an issue but no clue about where to look. If a program using exactly this kind of approach would exist (let me know in this case, thanks!), these could be an example of steps to go through in order to find out what files need to be inspected:
- Open the graphical dependency tree.
- Select all files you think could be useful to restore.
- Set till which older version you want to end testing.
- Each version combination could be (almost) automatically tested by running user-defined commands (e.g. displaying an internet page or executing a bash script) for each of such combinations.
As result, the programmer would be able to observe such outputs, recognize the one which is working and see which file versions are associated with that.
Additional functionalities as saving in some folder two file versions can be useful for further elaborations. For example, if you use Windows, a nice program to easily compare two files/folder is Winmerge.
Note: this approach could be integrated with Git and even use Git commands to implement the described functionalities.