Re: Repository Issue - Locking error on deleted files

If you must, must have file locking on checkouts, Subversion isn't for you.
Subversion does not really even do file locking as much as advising that a
file is locked. Anyone can break a lock on a file.
That said, this is the modern way of doing revision control and the position
is clearly explained in the Subversion book <
http://svnbook.red-bean.com/en/1.5/svn.basic.vsn-models.html#svn.basic.vsn-models.problem-sharing>.
Almost all newer revision control systems no longer require a user to lock
files when doing changes.

What you've discovered is that you don't need a lock to delete a file in
Subversion. This makes perfect sense: Locking in Subversion is to prevent
one user from attempting to change a file that merging doesn't work for.
Such as a GIF.

Imagine if I spent a lot of time and effort modifying a GIF. Without
locking, someone else could checkout and modify that GIF file. I would then
be unable to commit my change, but doing an update won't work because unlike
a text file, my changes and the other user's changes won't be merged.
Instead, I would be forced to revert my changes, do an update, then redo my
changes on the new GIF. Locking would at least let the other user know that
I am busy making my changes, and they will have to wait their turn. (Or, if
I checked out and locked the GIF, then took two weeks off, they could break
the lock on the file. But, at least they know I'm working on that particular
file.)

When I do a delete, I don't need to worry about merging someone else's
changes into that file. After all, the file is deleted. If the other person
still needs that file, they can add it back into the repository. Thus, file
deletions don't need locks. Neither do file adds, moves, or copies.

My suggestion is to remove the svn:needs-lock attributes on all files unless
they are the type of file where you don't need a merge. Let Subversion work
the way it is intended to work.

Now, to your particular issue: I am not sure how to fix your issue in
TortoiseSVN, but in regular Subversion, you can break a lock via the "svn
unlock --force" command. You can use the URL to help break the lock. I
always tell my developers that if they run into an unattanable situation
using Eclipse or TortoiseSVN, to go to the command line and try solving the
issue that way.

--
David Weintraub
qazwart_at_gmail.com
On Thu, Nov 27, 2008 at 9:14 AM, Cadyn Bridgman <cbridgman_at_gmail.com> wrote:
> Hi,
>
> I've got a rather perplexing problem on one our subversion repositories.
> The situation is as follows:
>
> *Configuration*
> We are running VisualSVN version 1.1, which runs Subversion 1.4.6. I have
> configured each repository to enforce file locking via a pre-commit hook.
> If a file doesn't contain the svn-needslock attribute, the repository will
> not allow the file to be committed.
>
> *Problem*
> As for the problem, I don't know exactly what happened, but the basic story
> is: One of the developers removed a number of files from the repository
> while having a lock on those files. If one navigates the repository using
> the TortoiseSVN repositry browser, the deleted files cannot be found/seen.
> The problem came in when he tried to commit a new file with the same name as
> one of the ones which was deleted, and received a message which stated that
> the file already exists.
>
> *Attempts to fix it*
> I have tried to delete the folder containing the problem files, but I get
> the following error:
>
> *Deleting:
> D:\Work\I-Intelligence\Repo\Deloitte\CRM\branches\dev\Development
> Error: Commit failed (details follow):
> Error: User SVNBackups does not own lock on path
> '/CRM/branches/dev/Development/Source/CRM
> Service/CRMService.Model/CRMService.Model.csproj.vspscc' (currently locked
> by mpalmer)
> Error: If you want to break the lock, use the "Check For Modifications"
> dialog.*
> I cannot lock that file because I cannot get it out of the repository. If I
> run an update, that file is not included in the ones retrieved from
> subversion.
>
> I have also tried running the standard repository recovery command:
>
> *C:\Program Files (x86)\VisualSVN Server\bin>svnadmin recover
> D:\Source_Control\Repositories\Deloitte
> Repository lock acquired.
> Please wait; recovering the repository may take some time...*
> *Recovery completed.
> The latest repos revision is 63.*
>
> It runs pretty much instantly and reports no problems.
>
> At this point, short of deleting the repository and loading everything in
> again, I have no idea how to solve this issue. Can you tell me if there are
> other things I can try in order to resolve this? Please let me know if
> there's anything else I can tell you which might be of help.
>
> Regards,
> Cadyn Bridgman
>