IBM Rational Change and Synergy for Change Management

IBM Rational Synergy:

IBM Rational Change:

I have used this product for over 2 yrs now and here are a few tips:


  1. Create SR (Service Request) to get access to the project (Note that the Project name is within the Solution).
  2. Once SR is approved, copy the Project to file system for working on it.
  3. Next, Create a CR (Change Request) and describe the change that you will make to the project.
  4. Then assign the CR yourself (or someone else)
  5. Next, after the change is made to the code base on your local copy, you have to check it in.
  6. Open IBM Rational Synergy Windows Applicaion.
  7. Do Update Project
  8. Do “Sync Work Area”
  9. Select the files that you want to check in (Note that you shouldn’t check in the Build files like Bin, Suo etc., only the Source Code should be checked in).
  10. Next, select Keep Work Area Changes (after discarding other files).
  11. This will prompt you for task ID
  12. Here, clk on CR button to create a New Task for your CR.
  13. Next complete the Task to check in the code ((NOTE: If u wanna see the changes specifically in that task, select the change file under the task in the sidebar and select Compare With Predecessor in its options)
  14. Finally go the the Rational Change web client to complete the CR.


  1. Creating Baselines and Versions
    1. You may want to create Baselines at imp stages.
    2. While creating a new version, make sure you Turn Propogation On, so that the Bug fixes in the old version are automatically present in the new version as well.

2.      Referencing a 3rd party Dll in Synergy

a. The rule with 32rd Party Dlls is that they should not be directly checked into your code as a local copy.

This way, when it us updated by the owning group, you will not get the update.

Instead, search for the dll in synergy (with Is Product =TRUE) and Find Object, not Task

Then when you find it, copy and paste it withing your project in synergy only…



Using Git Extensions in Visual Studio

Using: Open Source Git Extension 2.4


  1. In the GIT tab in VS, select Clone
  2. In case u don’t have the release responsibility, clone the develop branch only
  3. Once done, do File -> Open Solution
  4. Checkout Branch to switch Branches (rt clk on the coln in VS soln explorer)
  5. To switch to Develop branch of Stash, select origin/develop (origin means Stash)
  6. Soln Explorer shows the current branch in brackets on the Top
  7. For every change create new branch
  8. So rt clk on soln -> Git -> New Branch (This is called Feature Branch)
  9. Then make the changes and do Commit.
  10. This will commit to the new branch (This is called Staging)
  11. Then Push (ie Merge) with the Develop Branch in Stash
    1. For this first do checkout Branch -> Local -> Develop
    2. The Pull from Remote origin Develop Branch to get the latest Updates
    3. Then select Merge (Note that in its Form, merge with actually means Merge From)
    4. Then Push to Remote -> Develop from Local Develop

(Verify the change in Stash Develop Branch)


Then Do Integration Build

  2. We need to Merge with Master
  3. 1st Pull from Remote Master to local master
  4. Checout Master
  5. Merge loca develop with local master
  6. Push local Master to remote Master


(Verify the change in Stash Master Branch)



  1. edit .gitignore file can be edited from the rt clk menu itself


Git Workflow: Getting Started


  1. Copy Project
    1. git clone <repo-url> [ <new-repo-name> ]
    2. cd <repo-name>
    3. git checkout develop
    4. git branch <branch-name>
    5. git checkout <branch-name>
  2. Modify Source
    1. git status
    2. git st (more terse: status –sb)
    3. modification types:
      1. create a new file
      2. edit an old file
      3. move (rename or relocate) an old file
      4. remove an old file
  3. Stage Changes
    1. git add <pattern>
    2. git rm [-r] <pattern>
    3. git mv [-f] <source> <destination>
  4. Commit
    1. git commit [-m “<message>” | -F <filename>]
    2. git commit –a –m “<message>”
    3. git commit –amend [-m “<new-message>”]
  5. Continuous Integration (For this use the ‘develop’ branch)
    1. “P.U.M.P” the code – pull updates, merge, push.
    2. git pull
    3. git merge <from-branch>
    4. git push [<remote>] [<branch>]
  6. Release (For this use the ‘master’ branch)
    1. Push to master




Mercurial and Git

What is the Difference Between Mercurial and Git?


They both work with the same
abstractions: a series of snapshots (changesets) which make up the history.
Each changeset knows where it came from (the parent changeset) and can have
many child changesets. The recent hg-git extension provides a two-way bridge
between Mercurial and Git and sort of shows this point.

Git has a strong focus on mutating
this history graph (with all the consequences that entails) whereas Mercurial
does not encourage history rewriting, but it’s easy to do anyway and the
consequences of doing so are exactly what you should expect them to be (that
is, if I modify a changeset you already have, your client will see it as new if
you pull from me). So Mercurial has a bias towards non-destructive commands.

As for light-weight branches, then
Mercurial has supported repositories with multiple branches since…, always I
think. Git repositories with multiple branches are exactly that: multiple
diverged strands of development in a single repository. Git then adds names to
these strands and allow you to query these names remotely. The Bookmarks
extension for Mercurial adds local names, and with Mercurial 1.6, you can move
these bookmarks around when you push/pull..

I use Linux, but apparently
TortoiseHg is faster and better than the Git equivalent on Windows (due to
better usage of the poor Windows filesystem). Both and provide online hosting, the service at Bitbucket is great
and responsive (I haven’t tried github).

I chose Mercurial since it feels
clean and elegant — I was put off by the shell/Perl/Ruby scripts I got with
Git. Try taking a peek at the file if you want to know what I
mean: it is a shell script which generates a Ruby script, which I think runs a
webserver. The shell script generates another shell script to launch the first
Ruby script. There is also a bit of Perl, for good measure.

I like the blog post that compares
Mercurial and Git with James Bond and MacGyver — Mercurial is somehow more
low-key than Git. It seems to me, that people using Mercurial are not so easily
impressed. This is reflected in how each system do what Linus described as
“the coolest merge EVER!”. In Git you can merge with an unrelated
repository by doing:

git fetch

git-read-tree FETCH_HEAD

git-checkout-cache -a -u

git-update-cache –add —
(GIT_INDEX_FILE=.git/tmp-index git-ls-files)


git commit

Those commands look quite arcane
to my eye. In Mercurial we do:

hg pull –force

hg merge

hg commit

Notice how the Mercurial commands
are plain and not special at all — the only unusual thing is the –force flag
to hg pull, which is needed since Mercurial will abort otherwise when you pull
from an unrelated repository. It is differences like this that makes Mercurial
seem more elegant to me.

Git is a platform, Mercurial is
“just” an application. Git is a versioned filesystem platform that happens to
ship with a DVCS app in the box, but as normal for platform apps, it is more
complex and has rougher edges than focused apps do. But this also means git’s
VCS is immensely flexible, and there is a huge depth of non-source-control
things you can do with git.

That is the essence of the

Git is best understood from the
ground up – from the repository format up. Scott Chacon’s Git Talk is an
excellent primer for this. If you try to use git without knowing what’s
happening under the hood, you’ll end up confused at some point (unless you
stick to only very basic functionality). This may sound stupid when all you
want is a DVCS for your daily programming routine, but the genius of git is
that the repository format is actually very simple and you can understand git’s
entire operation quite easily.

For some more
technicality-oriented comparisons, the best articles I have personally seen are
Dustin Sallings’:

The Differences Between Mercurial
and Git

Reddit thread where
git-experienced Dustin answers his own git neophyte questions

He has actually used both DVCSs
extensively and understands them both well – and ended up preferring git.

There’s one huge difference
between git and mercurial; the way the represent each commit. git represents
commits as snapshots, while mercurial represents them as diffs.

What does this means in practice?
Well, many operations are faster in git, such as switching to another commit,
comparing commits, etc. Specially if these commits are far away.


3.       SVN
vs DVS


revision control uses a peer-to-peer model rather than using a centralized
server to store code updates. While a peer-to-peer model would work better for
world-wide, open source projects, it may not be ideal in other situations. The
downside to a dedicated server approach is that when the server is down, no
clients are able to access the code.

( began close to the same time as Git and is also
a distributed revision control tool. It was originally made to compete with Git
for Linux kernel development, and as Git was selected, Mercurial has seen less
success in that area. However, that is not to say that it is not used as many
major developments use it, including It’s different from other
revision control systems in that Mercurial is primarily implemented in Python
as opposed to C, but there are some instances where C is used. Due to its
distributed nature and its creation in Python, the Python language developers
are considering a switch to Mercurial as it would allow non-core developers to
have easier access to creating new trees and reverting changes.

Some of the major
drawbacks to Mercurial include that it doesn’t allow for two parents to be
merged and unlike Git, it uses an extension system rather than being
scriptable. That may be ideal for some programmers, but many find the power of
Git to be a feature they don’t want to trade off.









Git Tips II

SSL Certificate Error while cloning repository from Git

Run this on the Git Bash: git config –global http.sslVerify false

The branch name should be the same name as the Tkt name to avoid

The master always contains the latest code and hence the local changes
should be made to the Branch and not to the master.

Git add –all to stage all the changes before committing. Post this, git
status will not show the changes

Do git pull origin develop before pushing the changes of develop out…

Git checkout develop to switch to develop branch

Then if there are no conflicts do git merge <developBranch>

Then push it out: git push origin develop

Finally  do checkout master and merge develop , then push it out
(git push origin master)

11.   Ok
so found that the view of the Code in Windows Explorer is dependent on what
branch we are on, and changes that way.

12.   Also
note that in case u make changes to 1 branch and not commit that, then they
will be visible in the other branches as well. So better commit before changing
in other branches.

13.   Also
note that in GitHub, there is always Master and Develop Branch only and so for
versioning we have to create a new release branch, which will contain the 1.0
code and then that, when merged with Master will trigger a rel build for 1.0

14.   All
developers have Develop and Master in their local file system and whenever the
check in code into GitHub develop, it triggers a remote integration build and
when they checking code into GitHub Master, it triggers a Release Build.

15.   Make
changes to develop and commit it in master. This way you’ll be able to commit
any change in any Branch. Also, when u commit the develop branch’s change in
Master, It gets discarded from the develop branch and then going back to
develop u don’t see the change in develop anymore (git status)… Then the only
way to get the change in develop is to merge it with master…

16.   Start
by taking clone of master then create local develop and then into that develop,
pull from the remote develop and then start working.

In case there are multiple remote branches, on doing Git Clone, it will map only the local master to the origin/master.

To track other remote branches, do :

$ git checkout –track origin/develop
Branch develop set up to track remote branch develop from origin.
Switched to a new branch ‘develop’


How to stop tracking a file without removing it from repo


SourceTree for Windows

Get it here:

SourceTree is a powerful Git and Mercurial desktop client
for developers on Mac or Windows.

Say goodbye to the command line and use the full
capabilities of Git and Hg through SourceTree’s beautifully simple interface.

I have just started using it for Git and it looks quite
Powerful…Will share more as I use it




Using Git Bash. Workflow for Developers

1.       Can do ls –la, vi, vim etc. commands in it.

2.     It is a command line tool

3.       Git clone <URL> <name of dir>

4.       Cd <name of dir>

5.       Git branch

a.       Will show master only as that’s what we cloned

7.       Git branch –all

8.       Ticketing System

a.       Should be in progress for commit to work..

b.      Create a new branch for every tkt

9.       Git branch <MyNewBranch>

10.   Git checkout <MyNewBranch>

a.       Need to be in the branch to make  changes to it

11.   Ls –la

12.   Vi <editThisFile>

13.   Git status

a.       Shows
the status of changed files

14.   Git add <FileToStage>

15.   Git add –all //
To stage all files

16.   Git commit –a –m
//Stage and commit all changes in one shot

a.       Even
commit is a local operation and does not push your code out.

17.   Git status
//gives the status of files in the current Branch at all times

18.   Git commit –m <filename
test commit> //tkt name

19.   Git checkout
develop … then git merge <myLocalBranch>//Merge the changes of your branch to the remote branch

a.       Before u merge, make sure u do an update to prevent conflicts

20.   Git push origin develop//Push local develop branch to github

a.       Any push will trigger CI Build in Rel Build Tool

21.   Goto github
-> ur Repo and Commit Tab //Confirm code in github and its Ticket

22.   To make the changes available in Master (and automatically trigger Rel Build in Rel Build System).

a.       Git pull origin develop//Get changes to local repo

b.      Merge local with master

i.      Git checkout master

ii.     Git pull origin master // make sure its up to date too

iii.   Git merge develop

c.       Git push origin master//Push to github

23.   TIPS

a.       Git – help

b.      Jive
-> Search for ALM for FAQs