FROM:http://blog.vectorcomputing.net/2010/01/05/loading-a-repository-workspace-with-team-concerts-command-line-scm/
Another Link From Infocenter:http://pic.dhe.ibm.com/infocenter/rtc/v2r0m0/index.jsp?topic=/com.ibm.team.scm.doc/topics/r_scm_cli_scm.html
The Rational Team Concert “Client for Eclipse IDE” packaged as a ZIP file (as opposed to the “Local Install”, which uses IBM Installation Manager) includes an easily extractable command-line tool for performing nearly all of the actions possible in the GUI version on any platform that supports a modern JVM. This is great news for users unable to run the full Eclipse IDE client.
Prerequisites
There are three things required to run the command-line scm tooling:
- An appropriate JVM must be available to the host(s) to be supported.
- The ‘scmtools’ folder must be available to the host(s) to be supported.
- A few files need to be modified to support use of the decoupled ‘scmtools’ folder with different platforms and JVM locations.
Acquire Java
Out of the box, the scm tooling was packaged to use the JVM included with the full RTC Eclipse client. However, the downloaded client only includes the JVM for the platform selected (Linux or Windows). The goal is to run the scm tools on a variety of platforms. Therefore, the appropriate JVMs should be acquired for the platform(s) to be supported. At present, Java 1.5 is the minimum supported version. However, given that Java 1.5 is past its standard service life, it would not be unreasonable for the RTC developers to require 1.6 in the near future.
Extraction of ‘scmtools’
The target host(s) need access to the “scmtools” folder included in the full RTC Eclipse client. After downloading the client, extract the “jazz/scmtools” sub-directory from the ZIP file.
A typical unzip command might look like this:
unzip RTC-Client-2.0.0.2-Linux.zip "jazz/scmtools/*"
This will result in a ‘jazz/scmtools’ directory being created. The ‘scmtools’ folder should be around 55MB in size (as of 2.0.0.2).
The ‘scmtools’ folder does not require write access for the tools to function properly. Read-only access is not only acceptable; it may even be preferable. If a small number of hosts are to be supported, it may be easiest (initially) to copy the ‘scmtools’ folder to the hosts and notify users of the location. If a larger number of machines are to be supported and centralized maintenance is desired, using a common network shared directory, such as via NFS, along with a collection of scripts to simplify scm tool access for multiple platforms may be preferable.
Configuration
There are three files in ‘scmtools/eclipse’ directory that need to be modified to decouple the scm tools from the supplied packaging and to support different platforms:
- scm.ini — the value passed to the -vm argument changed to point to an appropriate JRE ‘bin’ folder for the platform.
- scm.sh — the first argument to exec needs to point to an appropriate ‘java’ binary for the platform.
- lscm — Change the Java invocation command from “${PRGPATH}/../../client/eclipse/jdk/jre/bin/java” to point to an appropriate ‘java’ binary for the platform.
Lastly, read through the file ‘CommandLine_Readme.txt’ as it may contain additional information applicable to your usage.
Running
After completing the above steps, you should be ready to try out the tools. There are two ways to run the scm tool, each with trade-offs:
- Using the ‘scm.sh’ script loads a complete Java/Eclipse environment and all plug-ins from scratch. The disadvantage of this method is that it must load the JVM, Java classes, and Eclipse plug-ins with every command invoked and this can be bit slow. Even on an archaic system, the performance is bearable. The advantage is that the required memory to run the scm tools is only consumed during command invocation as the JVM shuts down after every command.
- Using the ‘lscm’ script loads a daemon on the initial invocation and re-connects to an already running daemon on subsequent invocations. When performing many scm operations, this method is appreciably faster. The disadvantage is the daemon stays in memory continuously. Unless you are on a very tight memory budget, I recommend using the ‘lscm’ method.
Listing Workspaces
$ scm.sh list workspaces -r "the repository URL" -u "my user name" -P "my password"
(1000) "LWF DSA Exploration"
(1001) "LWF Upgrade Assistant Exploration"
(1002) "LWF ARCS Exploration"
(1003) "LWF Informix JDBC"
(1004) "LWF UTM Workspace"
(1005) "LWF Apache Derby"
The help for the load command has the following to say:
$ scm.sh help load
Help on load
Load the contents of the specified workspace into the local filesystem. By default, the workspace is loaded into a subdirectory of the current working directory named the same as the provided workspace selector.
Usage: scm load [options] [remote-path...]
ws-name - Workspace to load (name, alias, or UUID).
remote-path - List of remote items to load, may be a component (name, alias, or UUID), or a remote path within a component.
Options:
--all - Selects all components. Priority is given to explicitely selected components in the case of a conflict.
-d [--dir] arg - Root directory to save files to.
-f [--force] - Overwrite files that already exist in the filesystem.
-i [--include-root] - Load component roots as directories in the filesystem.
-L [--local-rules] arg - Local path to load rules. Must be specified with exactly one component.
-P [--password] arg - Password for repository.
-q [--quiet] - Print the minimum of output during normal operation.
-r [--repository-uri] arg - URI specifying the location of repository.
-R [--remote-rules] arg - Path to the load rules within a component. Must be specified with exactly one component.
-t [--target] arg - Optional local path where changes should be loaded
-u [--username] arg - Username for repository.
So, assuming I want to load the “LWF UTM Workspace”, which has ID 1004, I could type:
$ scm.sh load --all -r "the repository URL" -u "my user name" -P "my password" 1004
This could also be done using the name of the workspace, I feel that using the ID is easier to do with precision.
Using ‘lscm’
Using lscm is simple. So, we will add another variable to things to show how I would use RTC for work. RTC roots itself in the directory you login at. It expects that all operations will take place at or below that directory. So, assuming you are starting from scratch and want to be able to work with multiple workspaces in a convenient manner, your best bet is to start by creating a top-level container directory. A good name for this might simply be ‘RTC’. If the home directory is local, I typically place it there. If the home directory is from an NFS mount, I typically find a folder that is contained on a drive local to the machine and put it there, with some appropriate name such as ‘RTC-lfeagan’ or make a parent folder ‘lfeagan’ and a sub-folder ‘RTC’. Try to exercise some good judgement, remembering that the daemon is local to the host. Using the same NFS shared folder on multiple machines for RTC is likely a recipe for disaster.
- ‘cd’ into the directory created for loading workspaces.
- Decide on a name for the workspace you want to load, ‘mkdir’ it, and ‘cd’ into it. While this is not required, it helps keeps my life slightly more sane.
- Login to RTC and give the repository a nickname
$ lscm login -r "the repository URL" -u "my user name" -P "my password" -n "lxrtc"
Logged in to "the repository url"
- To check that your credentials were stored, use lscm list credentials.
$ lscm list credentials
- When performing subsequent scm operations, simply give the nickname as the repository url. For example,
$ lscm list workspaces -r lxrtc
- Load up a workspace,
$ lscm load --all -r lxrtc "Workspace Name"
Accepting Other’s Changes
The ‘lscm status’ command is the CLI equivalent of the ‘Pending Changes’ view in the Eclipse client. It shows incoming, outgoing, conflicting, and suspended change sets.
Creating a Changeset
After loading a workspace you begin to work on code. At some point in time, you decide you want to begin a change set. Remember, change sets are associated with components. If you are in a folder that is associated with a component when you invoke the ‘lscm create changeset’ command, it will automatically pick up on this fact. If this is not the case, for instance if you are in the root of the workspace you loaded, you will need to specify the component by using the ‘–component’ flag. After creating a change set, running ‘lscm status’ will show the new outgoing change set. To add file(s) to the change set, use the ‘lscm checkin’ command. If you only have one change set, then it is also the active change set. If you have more than one change set for the component, you will need to specify the change set to checkin the change to using the ‘-c’ or ‘–change-set’ flag.
Delivering a Change Set
When you have completed work on your change set(s), you can deliver one or more change sets that cover one or more components simultaneously using the ‘lscm deliver’ command. Typically you will run ‘lscm status -C’ and ‘lscm diff changeset “changeset id” -r “repository nickname”‘ to review the changes that are part of the change set before delivery. After reviewing the changes, the change set can be delivered with ‘lscm delvier “changeset id”‘.