My guess is that this is what's happening (in my case): I have two nightly build processes creating tags. #1 and #2 both run at around the same time. Perhaps #2 starts while #1 is still running and then Subversion tells us that something is changed (optimistic locking).
There are probably 2 ways for me to fix this: 1. Schedule one build 15 minutes later (which I am trying) 2. Wrap my svn copy command in a shell script and add some retry logic Thanks for your explanation of what's happening here! Andreas Krey wrote: > > On Thu, 23 Feb 2012 14:10:22 +0000, Stefan Sperling wrote: > ... >> > svn cp --username=user --password=******** 'http://fromurl' >> > http://tourl/tags/builds/4.1.3.0_20120223.0 -m 'Nightly build tag >> created by >> > CI' >> > svn: File or directory 'tags/builds' is out of date; try updating >> > svn: resource out of date; try updating > > At the very least the error messages are misleading: > There is nothing that could be updated in this case. > >> Server-side copies can fail if they compete with concurrent commits. > > Seriously, what competition? What reason even is there to allow > a purely server-side operation to run into a can't-continue state > due to other commits -- and not let those commits (that are late > to the race to begin with) fail? > > The message should really be > > svn: I don't feel like it, please retry. > > Andreas > > -- > "Totally trivial. Famous last words." > From: Linus Torvalds <torvalds@*.org> > Date: Fri, 22 Jan 2010 07:29:21 -0800 > > -- View this message in context: http://old.nabble.com/svn-copy-randomly-gets-%22File-or-directory-is-out-of-date%22-error-tp33377417p33378402.html Sent from the Subversion Users mailing list archive at Nabble.com.
