We have a recent requirement at my workplace wherein we have a baseline Android project (trunk). Other projects will need to (svn) branch out from this baseline Android project and start their own line of development.
Now let's say that the current state of my svn is:
--r19--------r30----->my.package.baseline(trunk)
|
|--r24--r29------>my.newpackage.projectA(branch)
If I want to apply r30 to all my other branches, would it work fine if I do svn merge even if the directory/package has already changed due to r24?
If what you are asking is just would you able to commit, the answer is yes.
If you are lucky enough that files been changed in r24 and r29 are just different files with what's changed in r30, then it would just work without any problem.
If some files got changed in r24 or r29 has also been touched in r30 then you might run into a svn conflict, it will work still as long as the person perform the merge understand code changes in both branches(trunk and your branch), this person not just need to solving obvious svn conflict(same area in one file been changed in both branches), but also need to solve the code logic conflict, that I mean things like no svn conflict but it won't compile anymore, or the logic conflict between changes introducing new bugs in your code.
My suggestion here though, after the merge, commit immediately after solving svn conflict, don't worry about any logic conflict. You solve the logic conflict in a separate new commit. This will save your some rare trouble when you merge back into trunk from my experience. As what the svn does with the merge, it modify the mergeinfo attribute, for your example mergeinfo in your branch would be something like
trunk: r30
svn would be using this information to figure out how should it perform a merge when you decide to merge back into trunk, if your branch has everything from trunk to date, it simply replace trunk with your branch assuming your solved all conflict, if you do cherry-pick however, it use thing merge info differently to try to solve conflict automatically if possible, so if you commit logic fix in a different commit it would less likely run into svn conflict.
The longer a feature branch runs the more problem you would be facing if trunk keeps changing in the meantime. But it is what it is, that's how branching works, you should have a plan about how often you are going to merge from trunk and how long you want to keep your branch. Try to slice your task to smaller pieces so your branch has a shorter life span, for example two weeks, it would make a big difference comparing you keep a branch for three month and then merge back all those changes into trunk.