Re: EGit, TortoiseGit
"You shouldn't be working on the trunk then, only on a branch for future merging (I understand this is best practice, I've never merged branches myself except as pratice)."
A more likely scenario is someone creates a build branch from the trunk and then builds that and cherry picks commits from the trunk if something is needed to fix an issue. Git can do this too of course but it's still more effort than what I suggested.
"Wot, no conflicts, evar? #Really?# Surely bitchslaps SVN into the middle of next week!"
Of course there are conflicts occasionally in pulling (a combined fetch and merge) but not when pushing providing your clone is up to date prior to the push.
"Well, I may be misunderstanding but a pair of svn update calls in a batch file will update both working copies, no hassle. Failing that, svn switch to, well, switch a single working copy between two branches."
So you can hack something which lessens the effort of kicking off two updates but you still have to do it. And an svn switch is nowhere near as elegant given that it involves substantial server round trips to perform. Switching a branch in git is completely local to the machine because all of the history is there. It is so trivial to create and switch branches with git that developers would routinely do it to discrete bug fixes.
The simple fact is git is vastly superior to subversion in these scenarios. I've used enough source control systems to recognize their own individual strengths and weaknesses. Git (and mercurial) stomp CVS, Subversion and other VCS systems into a bloody pulp when it comes to scenarios like the above.