| | 11 | == Modifying Templates === |
| | 12 | |
| | 13 | Template editing in SCDB takes place in a ''working copy'' of SCDB repository. Edition itself is done with an editor. After the changes are ready for deployment (this generally involves [wiki:Doc/SCDB/Usage#TemplateCompilation compiling] them locally to check that everything is ok), the changes must be committed to SCDB repository using `svn commit` command or the equivalent in any other SVN client. To be able to deploy changes, you also need to important any changes in the repository and not yet in your working copy. This is usually done with `svn update` command. |
| | 14 | |
| | 15 | Instructions below are a vademecum for new Subversion users. There is in fact nothing SCDB specific. The examples are provided using the SVN command line interface. But all these operations can be done with any SVN client. For more detailed information, refer to [http://svnbook.org/ Subversion documentation]. |
| | 16 | |
| | 17 | === Creating a SCDB Working Copy === |
| | 18 | |
| | 19 | This is the first thing to do. Generally this is done in a permanent area, to avoid redoing it every time you need to do a modification. The SVN operation to do this is called ''checkout'' and can be done with the following command line : |
| | 20 | {{{ |
| | 21 | svn co http://mysvn.server.example.com/SCDB/trunk |
| | 22 | }}} |
| | 23 | |
| | 24 | This example assumes that the URL of template branch in SCDB repository is `http://mysvn.server.example.com/SCDB/trunk`. |
| | 25 | |
| | 26 | === Commiting Changes === |
| | 27 | |
| | 28 | After editing templates, [wiki:Doc/SCDB/Usage#TemplateCompilation compiling] them successfully and probably [wiki:Doc/SCDB/Usage#CheckingCompilationResults checking] the profile differences are ok, you need to commit your changes before being able to deploy them. To do this you need to use the following command : |
| | 29 | {{{ |
| | 30 | svn ci -m 'Message explaining the change' |
| | 31 | }}} |
| | 32 | |
| | 33 | ''Note : it is a good practice to always set a message when commiting summarizing the reason for the changes. Generally the description doesn't need to list the modified files as this information can be retrieved using `svn log -v`.'' |
| | 34 | |
| | 35 | === Browsing SVN Log === |
| | 36 | |
| | 37 | You can easily get the list of revisions and their associated description with `svn log` command. Without any parameters, this command displays the revision from the last one to the first one, starting at the revision the working copy is based on. As a commit doesn't update the revision the working copy is based on, this is a good practice to do a `svn update` first. Else you'll not see the last commited revisions. |
| | 38 | |
| | 39 | Also, this is generally convenient to limit the number of revision displayed. This can be easily done with one of the following options : |
| | 40 | * `--limit n` : display only `n` revisions. |
| | 41 | * `-r first:last` : display log from `first` revision to `last`. `first` can be greater or lower than `last` depending on the order you want. If there is only one number, only this revision is displayed. |
| | 42 | |
| | 43 | To know about the files modified during the revision, add option `-v`. |
| | 44 | |
| | 45 | === Updating a Working Copy === |
| | 46 | |
| | 47 | If you have an existing, out-dated, working copy and want to make new changes, there is no need to do a fresh checkout. Else, it is much quicker to update the existing working copy with last revision of repository contents. This is done with command : |
| | 48 | {{{ |
| | 49 | svn update |
| | 50 | }}} |
| | 51 | |
| | 52 | === Revert Changes === |
| | 53 | |
| | 54 | With Subversion it is very easy to revert changes, whether they have been commited or not. But the procedure is not exactly the same. |
| | 55 | |
| | 56 | To revert changes made to the working copy but not yet commited, you need to use `svn revert` command. This command requires one or several file/directory names. By default, it will revert only the given file or directory but not the directory contents. To revert a directory and all its contents (files and directories), you need to use option `--recursive`. |
| | 57 | |
| | 58 | ''Note : after a `svn revert`, changes are definitely lost.'' |
| | 59 | |
| | 60 | To roll back changes commited to the repository, you need to do a SVN ''merge''. This doesn't change anything in the repository but merge differences between 2 repository revisions in your working copy. To complete the rollback, you need to commit this merge, after editing some of the templates if needed. Then to deploy the rolled back configuration, you just need the [wiki:Doc/SCDB/Usage#TemplateCompilation normal procedure]. Conversely to `svn revert`, you cannot loose anything with a SVN merge : as the rolled back configuration is in the repository, you can roll it in again doing another merge. |
| | 61 | |
| | 62 | Typical command line for SVN merge is : |
| | 63 | {{{ |
| | 64 | svn merge -r HEAD:good_rev_num . |
| | 65 | }}} |
| | 66 | |
| | 67 | `good_rev_num` is the revision number you want to roll back. There are many ways to find it. Generally you browser the log with `svn log`. If you know the deployment tag (created by `ant deploy`) corresponding to the good revision, you can also display the log information for this tag with the following command : |
| | 68 | {{{ |
| | 69 | svn log -v --stop-on-copy http://mysvn.server.example.com/SCDB/tags/YY/MM/timestamp |
| | 70 | }}} |
| | 71 | |
| | 72 | The displayed information will tell you the trunk revision this tag is based on. |
| | 73 | |
| | 74 | There are in fact many possible variations in `svn merge` command. You can choose to revert a change between 2 arbitrary revisions and not only between the last one and a ''good one''. Also you can roll back the changes for only some directories or files. In this case you have to give 2 additional parameters : first one is the repository branch containing the directory/files, second one is the directory/file in the working copy the changes must be merged into. |
| | 75 | |
