Updating QWG Repository Trunk

Table of Contents

1. Merging change from a production SCDB

Normal development process for templates is to develop templates in a Quattor configuration database, where you can deploy the new templates in a real (test or production) environment. Only after, you have validated the modification in your environment, you should update the QWG repository.

New or modified templates should always be committed to the QWG repository trunk first, never directly in a branch or tag.

As much as possible, there should be one commit by elementary change. Avoid huge commit implementing many unrelated changes are they are more difficult to track and to revert. Also take care of putting useful commit message for each commit.

Merging change from a production SCDB

To help updating the trunk from a real Quattor configuration database (or vice versa), you should use directory-sync tool. This tool must be run from a SVN working copy (for example, a local working copy of QWG repository trunk). This is very critical as the tool will delete everything from the directory to synchronize and rely on SVN for being able to revert the deletion.

This tool updates a directory with the contents of a reference source, doing the following :

• For each directory existing both in QWG repository and in source tree :
  • Removes all .tpl files from the destination directory (the directory to update).
  • Copy all .tpl files from the source directory (built by appending destination directory name to source directory root)
• For each directory in the source tree and not in the repository, copy the tree from the source tree and add files to SVN QWG repository.
• For each directory in the repository but no longer in the source tree, do a svn rm of the directory.
• Show the differences with svn status

It accepts 2 parameters:

1. directory to synchronize: must be a relative path specification.
2. reference directory parent: the parent path where a directory with the same relative name is located and must be used as a reference source.

Note: because the second argument is not the source directory itself but a parent for a directory with the same relative name as the first parameter, when synchronizing a real configuration database with a QWG branch or trunk you must run this tool from cfg directory or one of its subdirectories.

It is quite important not to break the history when a template is moved from one location to another one. directory-sync is not able to detect the move: it removes the original one and add the new one. If possible try to run manually a svn mv to keep track of the move.

To process a directory hierarchy, directory-sync must called from find command. Look at the comments at the beginning of the script for the exact syntax. Here is an example, assuming your are at the top of QWG templates and your source tree is /tmp/scdb (last parameter of the command must be a directory containing the directories given to find that need to be relative) :

find grid os standard -type d -not -path '*.svn*' -exec tools/directory-sync {} /tmp/scdb/cfg \;

If you would like to do the opposite synchronization, to incorporate the QWG changes into your local database, assuming you have an up-to-date working copy of QWG templates in /tmp/qwg, you may use the following command from /tmp/scdb/cfg:

As you run this tool from a SVN workspace, you always have the opportunity to do a svn revert in case things went wrong...

find grid os standard -type d -not -path '*.svn*' -exec tools/directory-sync {} /tmp/qwg \;

If you want to synchronize only grid/glite-3.2 you could pass this directory as find first parameter and keep /tmp/qwgas the last directory-sync parameter, as the reference directory path will be built by merging both (/tmp/qwq/grid/glite-3.2).

You need to fix manually the unexpected differences. Unexpected differences are all the templates that existed in the repository but no longer exist in the local workspace or all the templates copied from the source but not registered in the repository. There are 3 situations :

• A template has been renamed or moved. In this case, you should revert the change for this template, do the relevant svn mv and rerun directory-sync to avoid breaking the template modification history.
• Else, if the template existed in the repository but is no longer present in the workspace (flagged ! by svn status), it can be safely removed from the repository with command :

  # To remove template template_name.tpl
  svn rm --force template_name.tpl
  # To remove all templates no longer present in the repository
  svn rm `svn status | grep '^\!' | awk '{print $2}'`
  

• Else, if the template is present in the workspace but not registered into the repository ((flagged ? by svn status) and this is a new template, it should be added to the repository with one of theses commands :

  # Add one specific template template_name.tpl
  svn add template_name.tpl
  
  # Add all the files not yet registered in the repository
  svn add `svn status | grep '^\?' | awk '{print $2}'`
  

When you have cleaned up the situation for all the templates, except those that are present in the workspace (because they are used in your local Quattor configuration) but don't need to be in the repository, you can do the final cleanup with :

rm -f `svn status | grep '^\?' | awk '{print $2}'`

When there is no more templates flagged as ! (missing) or ? (unknown), you can commit your changes to the repository. Please, take care of setting up a useful message for the commit as this is the only source for a ChangeLog...