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

Re: Locking Bugs?

From: Bill Mill <bill.mill_at_gmail.com>
Date: 2007-06-18 16:01:58 CEST

On 6/11/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> On 6/11/07, Bill Mill <bill.mill@gmail.com> wrote:
> No, the svn:needs-lock property is completely orthogonal to the
> existence of locks. The book explains in more detail.

I've read the book's section on it a dozen or more times, and posted to
svn-users, I assure you that I didn't post lightly.

Also, sorry for the delayed response; work has been crazy.

The problem here is that PQEbay/FilterConstants.cs is locked in the
> repository. Use 'svn info URL" to see information about the lock.
> (i.e. who locked it and when.)

So, what I ended up doing was doing "svn ci -m 'resurrected PQEbay"',
waiting for the error message, and then manually typing in the file name
that was returned as still locked, and unlocking it by URL. I did this
probably two dozen times.

If your working copy doesn't have the lock-token for the file, you'll
> have to break it forcibly with 'svn unlock --force'.

My working copy doesn't have the whole directory, could it still have had
the lock token for any of these files?

> If so, how can I remove it, or do anything to allow myself to check in?
> >
> > I've tried to lock the dir, but it's not checked in, so I get a catch-22
> > situation:
> Directories aren't lockable, only files are.

I spoke inaccurately; by lock the dir I meant "recursively lock all files in
the dir".

> == Issue 2 ==
> >
> > The second issue occurs when I've tried to delete a branch after
> > merging its changes into the trunk:
> >
> > /c/test/branches$ svn status
> > D ThreadedBoxCache
> > D ThreadedBoxCache\boxCache.cs
> > [snip]
> > D ThreadedBoxCache\Interop.MSCommLib.dll
> > D ThreadedBoxCache\InventoryGroupSorter.cs
> > D ThreadedBoxCache\frmSortStation.resx
> >
> > /c/test/branches$ svn ci -m "Deleting ThreadedBoxCache branch"
> > Deleting branches\ThreadedBoxCache
> > svn: Commit failed (details follow):
> > svn: Cannot verify lock on path
> '/snarf.root/APPLICATION/SecondSort/SortStation/
> > branches/ThreadedBoxCache/clsLotGroupBox.cs'; no matching lock-token
> available
> Once again, the clsLotGroupBox.cs is locked in the repository,
> probably by someone else.

I managed to do the same thing here as I did above, fortunately this time
there were only 2 files that I needed to unlock.

So, this leaves me with 2 questions and a statement:

1) Was there a better way to unlock the whole directory of PQEbay at
revision 1105?
2) What exactly is going on here? Shouldn't a file's lock expire (at least
for future revisions) when it's deleted? What use can there be of keeping
that lock around to haunt users in the future?

And the statement: Thanks for your help; you got me to a stable, fully
checked-in repo for the first time in months.

Thanks again,
Bill Mill
Received on Mon Jun 18 16:02:03 2007

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

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