If I understand you, you want to make sure that foo and bar share the same branch. foo is your master project and has an svn:externals on it somewhere pointing to bar. When you branch foo, you want to make sure bar is using the same branch. The only way to ensure that is to create your repository with the tags and branches directories at the root of your repository instead of at the root of the project (like most sites do).
Then you can use relative external references to point from the foo directory that contains the svn:external back to bar. Also, if you tag foo and bar with the same tag, foo and bar will maintain their relationship:
$ svn propset svn:externals ../../bar common
If your branches were at the root of your repository, then the common directory will be pointing to the same branch for foo as it is on bar.
The big problem with snv:externals is that if you're not careful, you're pointing to an ever changing version of the directory you're linking to. Let's say someone did this:
$ svn propset svn:externals /projects/bar/trunk common
in my foo project. I do a release and copy foo to a tag. However, the common directory that I've tagged will be modified when someone updates bar/trunk. This makes it almost impossible to rebuild foo.
When I use svn:externals, I always make sure I'm linking to either a tagged version of bar, or a specific revision, and if I am linking to a specific revision, I also peg my URL to that revision in case someone decides to delete the directory I'm linking to my svn:externals property.
There's nothing in Subversion that will automatically update your svn:externals properties, but you can search for all svn:externals on a directory tree by using
$svn propget -v -R svn:externals .
I've found that svn:externals usually ends up being a bigger pain than it's worth.
Instead, I simply store the built object of bar or a zipped up copy of the source in my release repository, and as part of my build procedure, I copy the object or zipped source out of my release repository.
I use Maven site repositories like Nexus or Artifactory as my release repository even if I am not doing a Maven project or even working in a Java based project. The local Maven repository provides all the tools you need to upload and download your dependent packages, plus Maven has the concept of release repository -- where the code never changes -- and a snapshot repository where you're planning on releasing the code, but it could change. This is helpful if you suspect that bar could change because of stuff you need in foo.
