This is a well known and acknowledged bug by the subversion devs. It affects a few subversion ebuilds, so I am proposing that until it gets fixed, the subversion eclass be changed to use cp -r in place of svn export. The problem, for those who don't know, is that svn export will not copy external trees over. This behavior is only supposed to happen when --ignore-externals is specified but it happens by default as well. There are two workaround. 1. The simpler and more sane way to workaround this bug is to use cp -r to copy the source from distrfiles to the workdir. 2. The other way would be to use svn export to fetch the tree direct from the svn server into the workdir. This would mean double fetching if you wanted a tree in distfiles, so i'm not going to put that as a patch up. I will suggest workaround #1, and include a patch for the subversion eclass.
Created attachment 77298 [details, diff] svn-export-workaround.diff Workaround #1 for subversion.eclass
added workaround to portage ... please file a new bug when `svn export` is fixed
The "cp -pPR" replacment was just fine. But the new "rsync -aC" version gives me lots of troubles. To be exact its the "-C" option of rsync. I have some dirs from repos not being copied now. First it was when .cvsignore files existed with stuff like "Makefile.in" inside. It didn't rsync those really important Makefile.in files. Now i have all .cvsignore files removed and it still doesn't copy whole dirs for some weird reason. Since its about subversion repos, is this problematic CVS option really needed?
For example the whole dir "core" is missig after rsync -aC http://svn.atheme.org/audacious/trunk/Plugins/Input/adplug/core
Reopened bug #129178 as it's the cause for the cp to rsync change. Leaving this bug closed.
especially since what you've posted has nothing to do with this bug at all
