Let's say I update my working copy out-of-band (*details below) - how do I have TortoiseSVN check the state of the working area against the server HEAD and update the local 'revision' info without having to transfer all the files (again) from the server? Right now my workflow is essentially to roll back the out-of-band updates, then do the SVN update (which re-transfers all of the files even though I already 'have them' locally) - I'd prefer to let the out-of-band updates stay and just have Tortoise detect that the files do, in fact, match the server...
*Details: This could be simply 'I get a zip file from my coworker with the latest changes (perhaps because that's faster than stupid-slow SVN...)', so I've intentionally abstracted the actual how from the question itself, but here are the details of my particular use-case.
I use git-svn to interact with a svn repo, but git-svn doesn't support Subversion properties, or at least not well - I tried, but remember there being some issues (possibly the requirement to update the file as well, as I want to adjust svn:global-ignores at the top level...). One way to handle that, as suggested in the linked answer, is to have a completely separate svn checkout to interact with those properties. This seems wasteful and even slower, so I set up my local git-svn clone to a directory called trunk and put that in the SVN checkout. Now I can get both to be 'happy' with some management and run ~updates from either direction - there are definitely some 'gotchas', but it's mostly manageable until we transition to git fully (soon).
I prefer to interact with git (or git-svn as applicable) as much as possible, so I usually run a git svn rebase, which pulls in incremental updates from the server. If I want to update the SVN side (e.g. so I can do a straight SVN commit to adjust just properties), I have to roll back the git repo to the local SVN HEAD and ask SVN to update the repo, which then pulls down all the files again and is just annoying. I'd like to just run git svn rebase, and then have TortoiseSVN confirm that the new working copy matches the server HEAD.
My first attempt was to leave the git-svn HEAD in place and run svn update --accept=working so it would just mark issues as resolved (since, uh, the HEAD did match - "trust me, SVN..."), but that apparently caused major issues in my SVN side when I tried to create an SVN commit the next time - it did not know what was going on...
