While merging a newer branch into a branch with lesser revno doesnot udpate the revno of older branch

The easiest to understand branch revnos is to use a graphical tool like 'bzr qlog' from the qbzr plugn.

'bzr qlog' inside your local branch will show you the relationship between revnos and revisions in your branch.

'bzr qlog trunk feature-branch' will show you both branches in the same view and especially which revisions are shared between the two branches (the revnos used will the ones from 'trunk').

'bzr qlog feature-branch trunk' will also show you both branches but using the 'feature-branch' revnos.

revnos alone are meaning less, they apply to a given branch and that's the only place they have a meaning. Moreover, they are guaranteed to be stable (each commit on this branch will receive an incremented revno).

When a given branch is shared between several developers because it's used to represent what is shared (the "official" branch, the "trunk", whatever you name it), the revnos from this branch being stable can be used among the developers because all developers have the same revno in their shared history.

When you start a feature branch from this shared branch, you start with a revno that is known to all. But each of your commits create a revno that is specific to your local branch.

When you merge back to the trunk and commit, you're creating a new revno on top of the shared ones and the local revnos you've created receive a new dotted revno in the shared branch.

If instead you merge the trunk locally inside your feature branch and commit, the revisions added to trunk since you branched from it becomes dotted revnos into your feature branch. This reflects the history of *your* branch and is not shared until you merge back to trunk.

Again, this is easier to grasp when looking at a visual representation like 'bzr qlog' provides, so experiment locally !