Repository symlinks may not work in partial exports

[blee]

Consider a module 'foo':

foo/etc/confman.conf

and a module 'bar' with a repository symlink to 'foo':

bar/etc/confman.conf -> ../../foo/etc/confman.conf

and a recipe 'baz' whose only module is bar:

bar

Running confsync on a machine with recipe 'baz' using recipe-style exports results in:

confsync[93785]: blee: install: invalid file mode: /tmp/confman.gGC2tHXo/confman.5PUG5F8K/bar/etc/confman.conf

And the file does not get installed.

[blee]

This issue can be worked around by manually using 'svn propset' to set confman properties on the symlink.

[ccowart]

This raises the question of what the desired behavior should be.

On the one hand, thus far, it's been a "feature" that unset
meta-data on a symlink falls through to the target file. This
allows you to change the ownership of the target, and, if not
overridden on the symlink, have that change affect the link
as well.

Given the "working copy" for exports isn't really intended
to make changes and subsequent commits, it might make
sense to have export find symlinks and do an svn propset
to propagate any unset properties from the target to the
link. These working copy changes would never be committed
back to the repository.

It's not all that clean, but it's the only way I can think of
to preserve the current feature set without too much work.
If the inheriting feature is deemed not worth saving, we
could have the link command deal with setting those
properties and write a repository migration for confadmin
that would cleanup existing repositories. I'm leaning
toward the first option though.