On Thu, Feb 23, 2012 at 03:24:54PM +0100, 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.
Yes, the error message is misleading. The client probably prints this message for any failed commit. We could try to make it print a different message for pure server-side commits. But I don't think this is a high priority issue (aka I'd review patches for this, but not work on it myself). > > 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? A server-side commit is a transaction, just like any other commit. There is no difference from the filesystem's point of view between a commit made from a working copy and a commit made only via URLs. Subversion does in fact attempt to reconcile changes from competing transactions before giving up. But this can fail for various reasons. Given the information provided in the problem report, the exact reason for the failure isn't entirely clear. Specifically, it isn't clear what the hypothetical concurrent commit is doing. So if my answer was a bit hand-wavy on details for you, I'm afraid I can't provide additional details without more information. > The message should really be > > svn: I don't feel like it, please retry. Oh, come on. I'm just going to suggest that you read the code of svn_fs_fs__commit_txn() if you feel like understanding the details.
