We currently have 2 branches:
/repo/branch/current_version
/repo/branch/next_version
current_version is a branch where all developers currently works.
We starting a next version and created next_version branch from some point in current_version, while work on current_version is still continuing. In next_version we do some development and in next months the branch will become our main one, where all development will be done.
Since there's development on current_branch, we thought periodically (say once per 2 weeks) to rebase next_version. This in order to keep both branch in sync, so when all developers will eventually drop current_branch and move to next_release, next_release will contain all current_branch's feature integrated and tested.
The problem is rebasing. Actually rebasing is merging latest commits of current_branch to next_version. So if I'll examine history of commited files in next_release, all I'll see is the merge commits and not the history (commits/authors/annotation) of current_version.
Do I miss something?
No, you haven't missed anything. This is a big problem with using SVN for version control.
I ran into it over and over again at my last job. Every time somebody committed something to current_branch (to stick with your terminology), the commit message would have to be copied manually so it could be used in the merge commit message. This quickly became a huge pain.
That's why new version control software has come out with better merging capabilities (Git, Mercurial, and Bazaar come to mind).
EDIT: Apparently SVN has fixed this issue. SVN 1.5 and up incorporate merge-sensitive logs and annotations. Use the flag --use-merge-history (-g) with svn merge and svn blame to see the commit messages from the merged branch.
来源：https://stackoverflow.com/questions/1507323/svn-rebasing-and-history-lost