| 52 | | The first approach is the easiest to code particularly as regards maintaining consistency between the subversion repository and the database: if the database ops fails we can simply avoid committing any changes to the subversion repository. If any of the subversion repository commits fail, then we can abort the database commit as well (it's not quite as simple as this actually!!!). However, excepting the simplest operations on a single record, the changes recorded in the subversion repository will bare little or no resemblance to the changes that are made by !GeoNetwork services. For example, if the user decides to change the privileges on a metadata record, this would result in more than one commit to the subversion repository (in fact the number of commits would be equal to the number of group permissions selected in the privilege interface as they are set one by one in the !DataManager). |
| 53 | | |
| 54 | | The second approach is more difficult to code: subversion changes need to be bundled by keeping the subversion commit editor open and using a listener to commit/abort the changes to the subversion repository when the database is committed/aborted. This scenario is complicated by the design of the tmatesoft api which does not allow reentrant calls on a subversion repository object and does not allow files and directories in the repository to be opened more than once in a transaction as described at http://osdir.com/ml/version-control.subversion.javasvn.user/2007-10/msg00053.html. |
| 55 | | |
| 56 | | The third approach is the one that has been implemented. The coding is much more straightforward than the second approach and only slightly more complex than the first. |
| | 52 | The first approach is the easiest to code particularly as regards maintaining consistency between the subversion repository and the database: if a database operation fails we don't make any changes to the subversion repository. If any of the subversion repository commits fail, then we could abort the current database commit. However, excepting the simplest operations on a single record, the changes recorded in the subversion repository will bare little or no resemblance to the changes that are made by !GeoNetwork services. For example, if the user decides to change the privileges on a metadata record, this would result in more than one commit to the subversion repository (in fact the number of commits would be equal to the number of group permissions selected in the privilege interface as they are set one by one in the !DataManager). |
| | 53 | |
| | 54 | The second approach is slightly more difficult to code: subversion changes need to be bundled by keeping the subversion commit editor open and using a listener to commit/ignore the changes to the subversion repository when the database is committed/aborted. This scenario is complicated by the design of the tmatesoft api which does not allow reentrant calls on a subversion repository object and does not allow files and directories in the repository to be opened more than once in a transaction eg. as described at http://osdir.com/ml/version-control.subversion.javasvn.user/2007-10/msg00053.html. |
| | 55 | |
| | 56 | The third approach is the one that has been implemented. The coding is slightly more straightforward than the second approach and only slightly more complex than the first. |
