PALM Revision Contrl

(1) Creating an svn branch

• Repository branch (only for admins)
  • @palm server: permissions to be set in /palmdata/conf/svn_authz file
  • svn copy ​https://palm.muk.uni-hannover.de/svn/palm/trunk ​https://palm.muk.uni-hannover.de/svn/palm/branches/<feature_name>
    -m "Branch for <feature_name> created."
  • (rename: svn move <path to old branch> <path to new branch> -m „...“)

• Local branch copy (for developers)
  • Create local working directory where the local copy of branch <feature_name> is placed, we recommend:
    mkdir -p ~/palm/branches
    The directory branches is on the same level as the directory current_version, where the official PALM releases/revisions (trunk) should be located
  • You can browse your branch under ​https://palm.muk.uni-hannover.de/trac/browser/palm/branches

(2 a) Checkout of local branch copy

• cd $HOME/palm/branches/
• svn checkout --username <your PALM username> https://palm.muk.uni-hannover.de/svn/palm/branches/<feature_name>

(2 b) Update of local branch copy

If the local branch copy already exists, and you would like to update it with a newer svn revision of this branch:

• cd $HOME/palm/branches/
• svn update <feature_name>

You can also update/downdate to or checkout a specific revision:

• svn update -r<revision number> <feature_name>
• svn checkout -r<revision number> --username ...

(3) Code development in local …

• ...svn branch copy
  Versioning happens when commiting to the svn repository branch. With every commit, the PALM revision number is incremented.
• ...git branch copy
  To avoid too numerous commits to the svn repository branch, local versioning could be done using git (→ follow steps on next slide)

NOTE: As you know, in order to compile and run PALM, the PATH and PALM_BIN variables need to be set in your shell environment
(e.g. .profile or .bashrc) as in this example:

#PALM SCRIPTS export PATH=$HOME/palm/current_version/trunk/SCRIPTS:$PATH export PALM_BIN=$HOME/palm/current_version/trunk/SCRIPTS

These paths need to be adjusted when you run PALM out of your ~/palm/branches/<feature_name> directory!
You might have to newly login to your system in order to activate these changes.
You can check the paths by typing echo $PATH or echo $PALM_BIN to your terminal.

An alternative to this approach is to use symbolic links to link .../trunk to .../branches/<feature_name>.
This way you don't have to keep changing the PATH/PALM_BIN variables, and you run PALM out of your current_version directory,
with your SCRIPTS/SOURCE files from ~/palm/branches/<feature_name>

(3 a) How to use git for local code versioning

(These are only brief hints, please refer to the git manual for more detailed help)

• Create local repository
  mkdir -p ~/git_palm/<feature_name>
• Rebase from svn feature repository
• Development under git (refer to manual)
• Manual copying of git SOURCE to svn SOURCE (<feature_name>) necessary
  • Why? → Due to PALM-politics of date-stamping of revision comments (git cannot do that)
  • Note: svn and git copy should have the same svn revision number r####
• Continue with svn procedure (see next slide)

(4) Synchronizing local branch copy with svn branch or trunk

It is wise to frequently synchronize your local branch copy with the latest svn revision of your branch (see Chap. 4a) and/or with the trunk (see Chap. 4b)
to stay up-to-date. Chap. 4a might become necessary if more than one developer simultaneously work on the same feature branch.

Please DO NOT mix up synchronization and other code changes in one commit, because when doing a diff of two branch revisions it‘s very difficult to find out the actual changes in the branch.

(4 a) Merge repository branch into local branch copy

1. cd $HOME/palm/branches/<feature_name>
   
2. svn update (takes care of merge here)
3. During update/merge, svn will print an alert in case the same line/block
   of code has been modified by the different developers. As an example:

Conflict discovered in file 'palm.f90'.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge, (mc) my side of conflict,
(tc) their side of conflict, (s) show all options:

We recommend to select (p)ostpone for all emerging conflicts, and after that, manually check/merge the contents of these files.
(Details in Chapter 4c)

4. svn resolved any_file.f90
5. svn commit (Details in Chapter 5)

Note: It might be wise to put a copy of your modified files somewhere else before you do the merge.