Applying the evolution radar to postgresql

In this report we describe the results of the application of our approach, the Evolution Radar [2], on the PostgreSQL system. The mining questions we want to answer are: 1. What are the relationships among the system modules in terms of logical coupling? How are these relationships character-ized? Which are the main responsibles for the logical cou-plings, i.e., the best candidates for starting a reengineering process? 2. How have these relationships evolved over time? When have refactorings been applied on the modules? In which phase is the system in the current version? 2. INPUT DATA To analyze the target system, i.e., PostgreSQL, we use its whole history, as recorded by the CVS version control system, stored in a database called Release History Database (RHDB) [1, 3]. The database populating process, performed in batch mode, consists in (i) doing a checkout of the system, parsing it and storing the structure information in the database, (ii) parsing the CVS logs and storing all the commit-related information. The RHDB includes information about all the files in the system,i.e., source code, doc-umentation, make-files, etc. For our analysis we consider only the source code data, i.e.,.c and.h files (since PostgreSQL is writ-ten in c). We decompose the system using the top-most directories in the src directory tree, i.e., we define a module as all the files belonging to a directory subtree. Copyright is held by the author/owner