[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Brenden Walker <BKWalker_at_drbsystems.com>
Date: Wed, 7 Aug 2013 20:07:30 +0000

> -----Original Message-----
> From: Bob Archer [mailto:Bob.Archer_at_amsi.com]
> Sent: Wednesday, August 07, 2013 2:30 PM
> To: Brenden Walker; Philip Martin
> Cc: users_at_subversion.apache.org
> Subject: RE: RESOLVED: SVN copy that worked in 1.8.0 now fails with (424
> FailedDependency)
>
> > > Brenden Walker <BKWalker_at_drbsystems.com> 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.
> > >
> > > 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.
> >
> > 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.
Received on 2013-08-07 22:08:10 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.