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
bill.mill@gmail.com
Received on Mon Jun 18 16:02:03 2007