When we do our branching and merging with svn, we always have the same thing happen.
We get a latest copy of the trunk.
Create a branch and switch.
They're probably mergeinfo properties. With version 1.5 of SVN, it was quite aggressive with setting the mergeinfo property, and as you merge, those properties get updated - requiring a commit to them.
The answer is to delete the mergeinfo property from them. Also upgrade to version 1.6 which has better mergeinfo support (i.e. it writes less of these properties).
I should say that these file will have no visible changes if you look at the differences. Obviously, if their contents are changed, then what the changes are may give you a clue (e.g. is an automated tool writing extra comments, modifying the layout or adding lines to the top or bottom).
EDIT: See this blog post for more information on SVN merging issues, and fixes.
Read the detailed article at http://www.collab.net/community/subversion/articles/merge-info.html
It's long but worthwhile. Note in particular the suggestions in the "Parting Thoughts" section at the end, which include hints for reducing mergeinfo noise.
Also, instead of using svn propdel to clean up unwanted mergeinfo, consider using svn merge with the --record-only option.
Most likely it is the mergeinfo properties as mentioned. You will probably want to clean up the mergeinfo properties on the files and folders in your trunk. A batch file is handy for this as you may need to do this sometime again in the future. Something like the following:
echo Removing Nested Merge Information...
svn propdel svn:mergeinfo subfolder1 --depth=infinity
svn propdel svn:mergeinfo subfolder2 --depth=infinity
svn propget svn:mergeinfo --depth=infinity trunk
Then commit back to trunk after you have ran the batch file on a working copy of trunk.
Also, renaming and moving folders is a common way to generate a mergeinfo property on a folder/file in a subversion repo. svn1.6 isn't as generous about adding the mergeinfo property for the various actions.
Personally, I think mergeinfo causes more problems than it solves, at least with the current state of the tooling. Once it's transparent on commits, maybe it will be worth using.
You can safely delete mergeinfo properties. However, be aware that you will need to manually track which revisions to merge for re-integrations.