Subversion rebase?

Question

I find this way easier to merge branches and less conflicts:

Copy trunk to a new branch, merge it with feature branch/s. When things done, merge the n

Answer 1

In my company we use following approach:

1. for each task NK-$X in the issue tracker we have a separate branch branches/NK-$X
2. we start work on a task by svn cp trunk branches/NK-$X
3. we never commit changes directly to the trunk. For each schedulled update UPDNK-$X we have a separate branches/UPDNK-$X. We create it with svn cp trunk branches/UPDNK-$X just before the update.
4. when the task NK-$X is schedulled for an update UPDNK-$Y we merge branches/NK-$X inot UPDNK-$Y. That is cd UPDNK-$Y; svn merge -r start:HEAD branches/NK-$X
5. after UPDNK-$Y is ready, we merge it to trunk. That is cd trunk;svn merge -r start:HEAD branches/UPDNK-$Y

If it happens that task NK-$X lasts longer than one iteration cycle, and therefore needs refreshing, we never, ever, NEVER merge trunk to NK-$X. We have a rule that you commit to your branch only things that you wrote yourself, which makes everything easier. Instead we do:

cd NK-$X
svn log
//let L = the number of the last changeset to this branch changeset
//let F = the number of the first changeset to this branch
svn rm branches/NK-$X 
svn cp trunk branches/NK-$X 
svn up
svn merge -r F:L branches/NK-$X@L 
svn ci -m 'refereshed'

This way, whenever you look at the changelog of branches/NK-$X you see only changes actually performed by the developer.

Update: Since the above workflow can be automated, I've started a project on github: svn rebase.