RE: NOT RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 FailedDependency)

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.