We have a commit hook that runs an 'svn update' on a remote working copy every time a commit finishes. Users want to see committed changes immediately reflected in this remote copy.
Users are extremely unhappy with the performance of running 'svn update' on the whole working copy, so I was asked to change the hook to use 'svnlook changed' to find updated files and then 'svn update' those updated files ONLY.
The performance of this method was received very positively, but this has put the working copy in a weird/broken state - the working copy gets the updates, but thinks it has local unversioned copies of the singleton-update files pulled from the repository.
I've been trying to understand the difference between a singleton update and a whole repository update to figure out why this is happening. Doing updates this way does not seem like good practice to me, especially given these issues, but I don't know enough about what's happening behind the scenes in SVN to articulate why, specifically the differences between 'svn update' and 'svn update FILE'.
What is different from SVN's perspective between running 'svn update' on the repository vs. on a file?
Is this a bad practice? Would parent directory-based updates be "good enough" practice?
Otherwise, how should I do SVN updates on a per-file basis to avoid this inconsistent working copy problem?