If it helps, the Subversion server binaries we provide at CollabNet have applied the patch that fixed this to Apache 2.4.6.
Sent from my iPad > On Nov 7, 2013, at 7:31 PM, Geoff Field <geoff_fi...@aapl.com.au> wrote: > > Sorry to dredge up an old thread, but this issue is NOT really resolved > properly. (Also, I noticed a post that said that this would be treated more > seriously if it was brought up again without the "RESOLVED" tag.) > > There's a known issue with the Apache server software > (https://issues.apache.org/bugzilla/show_bug.cgi?id=55306) whereby if the > directory tree being copied has a lock anywhere in it, the DAV component will > send a 424 error. Why a copy should need to be concerned about a lock is a > mystery. > > The so-called "Resolution" listed in the mailing lists here was simply to > break or release the locks. It's not really a fix, just a workaround. > > The most recent release of Apache is 2.4.6 from July, but the last activity > in the bug report is from October. Any idea when the next release is due? > The Apache release policy (http://www.apache.org/dev/release.html) doesn't > seem to tell me anything significant about that. (I do realise it's an open > source project and therefore dependant on people volunteering their time.) > > In the meantime, we will all have to continue trying to remember to unlock > files before attempting a branch, tag, or other copy. Either that, or revert > to an earlier version of Apache. > > >> From: Brenden Walker >> Sent: Thursday, 8 August 2013 6:08 AM >>> From: Bob Archer >>> Sent: Wednesday, August 07, 2013 2:30 PM >>>>> Brenden Walker writes: >>>>>>>> svn: E175002: Adding directory failed: COPY on >> /svn/Development/!svn/rvr/7020/Trunk/Projects/SiteWatch (424 >>>>>>>> Failed >>>>>>>> Dependency) >>>>>> >>>>>> Turned out that another developer had locks on several files. >>>>>> Confirmed that was the problem. A more specific >> error message >>>>>> would have been handy here. > > The error message was reasonably specific, but it actually points at another > bug. > >>>>> Can you describe how to reproduce the problem? What >> sort of locks >>>>> prevent a COPY? Orphaned locks perhaps? >>>> >>>> They were working copy locks from another developer. I >> asked him to >>>> try the build himself to see if it allows the user who holds the >>>> lock to svn copy, haven't heard back from that. > > ANY lock seems to work. I was able to reproduce the issue by locking the > files myself (and to "correct" it by unlocking the files. > >>>> Breaking the locks allowed me to do an SVN copy. >>>> >>>> I haven't tried reproducing, but I certainly can if that >> would be helpful. >>> >>> Are you sharing working copies with multiple people? >> >> If by that you mean checking out somewhere and having >> multiple people using the same working copy, no. Each >> developer has their own working copy. The reason the files >> were locked is that they're unmergeable binaries, AND most >> people here are still used to StarTeam. I offered up some >> other options to keep other developers from accidentally >> changing these files. > > We, too, have unmergeable binaries, so we use autoprops - including "needs > lock" properties as appropriate. This applies for even one-person teams (our > current default). > > > Regards, > > Geoff > > -- > Apologies for the auto-generated legal boilerplate added by our IT department: > > > - The contents of this email, and any attachments, are strictly private > and confidential. > - It may contain legally privileged or sensitive information and is intended > solely for the individual or entity to which it is addressed. > - Only the intended recipient may review, reproduce, retransmit, disclose, > disseminate or otherwise use or take action in reliance upon the information > contained in this email and any attachments, with the permission of > Australian Arrow Pty. Ltd. > - If you have received this communication in error, please reply to the sender > immediately and promptly delete the email and attachments, together with > any copies, from all computers. > - It is your responsibility to scan this communication and any attached files > for computer viruses and other defects and we recommend that it be > subjected to your virus checking procedures prior to use. > - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage > of any nature, howsoever caused, which may result > directly or indirectly from this communication or any attached files. > >
