| 61 | | Once drush is set up, BOINC features can be enabled with a few commands. First, create symbolic links in sites/all/modules/features-enabled pointing back to the desired feature module under sites/all/features. The following drush commands can then be used to list available features and enable them: |
| | 61 | Once drush is set up, BOINC features can be enabled via the command line. There are two methods by which to organize the filesystem in this regard, however: |
| | 62 | |
| | 63 | Symbolic links can be created in sites/all/modules/features-enabled pointing back to the desired feature module under sites/all/features. This method is clean and simple and any changes pulled from the source code repository will be instantly available (features will have the status of "overridden" and need to be "reverted" for changes from the source to be made live). |
| | 64 | |
| | 65 | An alternate method of organizing features code is to copy the files for each feature rather than use symbolic links. This can be more difficult to maintain, as the code in sites/all/modules/features-enabled may not match what is in sites/all/features, but it has the benefit of protecting features from being changed inadvertently by a source repository pull. If, for instance, the local version of a feature is in "overridden" status already due to local changes in configuration (within the database), this explicit separation of the live feature code base from the code repository allows the opportunity to update the feature code from the database and then compare any such local changes to changes pulled from the repository for merging. Using symbolic links in this case would have made it impossible to distinguish which changes came from the repository and which were local. |
| | 66 | |
| | 67 | Once one of the prior methods for features code organization has been implemented, the following drush commands can be used to list available features and enable them: |
