Thanks for explaining, I agree with your reasoning and it matches my initial thinking. My personal preference would be to never exclude and use proper sub-trees. However, assuming that there are valid reasons for exclusion, which is suggested by the fact it exists:
- If it affects the build, it's a misconfiguration to exclude something that matters. You want to run verification on relevant changes.
- If there are a lot of them, like developer docs needing locality to code, you don't want to be spammed with those changes
- When excluding noisy edits that aren't functionality related. The full changelog may actually do more to hide changes in noise.
- Ultimately, you want the misconfiguration fixed because you were wrong to exclude in the first place.
I can see valid cases where the changes in the excluded area are particularly long and it's unlikely they'll be affecting anything, docs for example. I also can see wanting to have those edits omitted from the stream rather than spamming on the next build. It's the same reasoning, but a simulation of http://svnbook.red-bean.com/nightly/en/svn.advanced.sparsedirs.html
One part of the reasoning is that these changes are actually checked out into the workspace, therefore I'd like to see them.
Other part is that even if you think that the changes may not be relevant for the build, you may be wrong and suddenly the build starts failing without any changelog entry.
Also I think that most of the time the additional changelog entries will do no harm, so I just would like to see them for completeness (see point 1