Reflective/Cyclic Merging
This is easiest to explain with an example. Suppose you are working on a feature branch copied from your trunk. During the development process you regularly merge ”all” new changes from trunk to your branch so that the branch stays in “synch” with the work occurring on trunk. When you eventually merge your branch back to trunk, that is called a reflective (or cyclic) merge.
Refer to Subversion merge reintegrate article on http://blogs.open.collab.net/svn/2008/07/subversion-merg.html for more details.
You can also refer to http://jugalps.wordpress.com/2009/07/31/svn-branching-and-merging-in-scrum/ to get an overview of a typical reflective merge process.
My personal experience with SVN is not good enough when dealing with such kind of scenarios.
Does any one have experience working with any other version control tool apart from SVN for reflective merging?
Git has always been designed with this ability in mind. It was my first VCS, and to me, this type of workflow is totally routine. In general, the merge (a push or requested pull) back to origin (“trunk”) is trivial, since by regularly merging from origin, you have ensured that your HEAD (branch tip) has origin’s HEAD in its past, so when origin merges your work, it merely has to move forward through the history, rather than actually perform a merge (git calls this a “fast forward”).
Git’s rebase capability can also be used to make the history even prettier. If you adopt this workflow, you can always rebase your work on top of whatever you pull from origin, rather than merging them. (This is rewriting history so you have to be sure not to do it with anything already published) That way, all of your merges from origin are fast forwards, and your work is just a single sequence of commits on top of origin’s HEAD. This makes the history more direct – hopefully a straight line, instead of a series of lots of merges.