These build breaks were caused by my common_resources change. I've fixed that (by removing the reference to the old common_resources checkout) but it highlights another problem.
This hudson build can't create a correct workspace if the workspace is deleted. The reason is that it checks out the federated build to harmony thus creating harmony/ working_classlib but this is not yet "svn switch"ed to the real classlib tree. Then it tries to check out harmony/working_classlib with the real url but sees the already svn checked out directory and refuses to overwrite it. The fix is to manually visit the workspace and "svn switch working_*" to the appropriate urls. I've done this for now. I think the only way to fix this and track the svn commits is to checkout the working_* trees to, for example, ignored/working_classlib and suffer the duplication. Tim, does that make sense? I don't think we can have builds that can't bootstrap their own workspace. Regards, Mark. In message <14752481.1091268475640815.javamail.hud...@hudson.zones.apache.org>, Apache Hudson Server writes: > > See > <http://hudson.zones.apache.org/hudson/job/Harmony-1.5-head-linux-x86_64/696/> > > ------------------------------------------ > Started by user hindessm > Building remotely on minerva.apache.org (Ubuntu) > Checking out a fresh workspace because the workspace is not http://svn.apache > .org/repos/asf/harmony/enhanced/classlib/trunk > Checking out http://svn.apache.org/repos/asf/harmony/enhanced/trunk > AU NOTICE > [snip] > ERROR: Failed to check out http://svn.apache.org/repos/asf/harmony/enhanced/c > lasslib/trunk > org.tmatesoft.svn.core.SVNException: svn: > '<http://hudson.zones.apache.org/hudson/job/Harmony-1.5-head-linux-x86_64/ws/harmony/working_classlib'> > is already a working copy for a different URL
