On this page:

Related topics:


This topic describes the differences in storing your source code in a standard build directory and a detached source directory when generating a snapshot.


When you generate a new snapshot of a project, a new snapshot directory is created as a subdirectory of the odasa/projects directory. This subdirectory contains a snapshot file that defines the location of the source code for the version you wish to analyze, in addition to the build commands, which are used when the snapshot database is generated. A copy of the source code may be checked out into one of two locations:

Standard source directories

For most systems, the standard method of storing a complete version of the source code in each snapshot directory is appropriate. You configure the project file with a checkout element containing a command that defines how to retrieve a full version of the source code. For example:

where ${src} is automatically expanded to the location of the new snapshot. For example: /home/example/odasa/projects/Hadoop/revision-2012-December-12--22-12-19/src.

Detached source directories

You should use a detached source directory in the following situations:

The project file is defined with a <checkout> command that defines how to update the source code to the required version. For example:

where ${src} is automatically expanded to the detached location for the project. The detached location is stored in the project file using the <source-location> element, for example: <source-location>/home/example/Ruby_source</source-location>.

Note that when reusing the same source directory for multiple builds, some build systems leave build artifacts in the source directory. These artifacts could potentially be picked up by later builds and then influence the results. In such cases care must be taken to ensure that the source directory is properly cleaned between builds (e.g. with make clean or similar commands).