SVN часто говорит, что файл заблокирован мной в другой рабочей копии

У меня есть репозиторий SVN (размещенный на Dreamhost) с установленной блокировкой потребностей для двоичных файлов. Иногда случается, что при фиксации файлов, заблокированных и измененных мной, фиксация завершается с ошибкой:

Error: Commit failed (details follow):
Error: File '/my/file.bin' is locked in
Error:  another working copy

Если я попытаюсь заблокировать этот файл (не украшая его), он скажет:

Error: Path '/my/file.bin' is already locked by user
Error:  'my_username' in filesystem '/home/user1/svn/repo1/db'

Очистка не помогает, поэтому единственный способ решить эту проблему - украсть блокировку, а затем выполнить фиксацию.

Это не критическая проблема, но она действительно раздражает, особенно когда это происходит в середине длительного коммита. Я склонен думать, что это вызвано ошибкой клиента или сервера, поскольку я уверен, что не использую другие рабочие копии, и проблема возникает у меня довольно часто (3 раза за последние два дня) и мои коллеги, использующие репозиторий.

Мы используем TortoiseSVN 1.8.4, а svn-сервер Dreamhost - 1.6.12.

Спасибо за любую помощь.

ОБНОВЛЕНИЕ: я заметил, что ошибка возникает, если я обновляю свою рабочую копию перед фиксацией (что не дает ошибок и, конечно же, не изменяет заблокированные файлы). Проверяя статус файла, черепаха перед обновлением сообщает, что он заблокирован мной (проверка только локально), а после локальной проверки обновлений выдает "????" как состояние блокировки, и, проверив сервер, он говорит, что он заблокирован мной. После обновления файл становится доступным только для чтения (из-за необходимости блокировки), даже если он все еще помечен как измененный. Таким образом, последовательность действий такова: заблокировать файл.bin -> изменить файл.bin -> обновить всю рабочую копию -> зафиксировать -> ошибка фиксации сбоя. После обновления рабочая копия, кажется, забывает о состоянии блокировки, и когда она запрашивает сервер, она считает, что заблокирована на другой рабочей копии.


svn tortoisesvn dreamhost
person cmant    schedule 18.02.2014    source источник

Ответы (5)


arrow_upward
41
arrow_downward

В Windows я решил проблему, выполнив следующие действия: 1. Запустите Repository Browser, щелкнув в меню «Repo-browser». 2. Найдите заблокированный файл. 3. Щелкните правой кнопкой мыши заблокированный файл. 4. Щелкните «Снять блокировку».

person Toby Han    schedule 10.10.2015

arrow_upward
3
arrow_downward

Очистка не поможет. Это используется для блокировок рабочей копии, тогда как вы сталкиваетесь с проблемой блокировки файлов в самом репозитории как средства реализации мьютекса между пользователями. См. Три значения слова "замок"

У вас, вероятно, есть клиент, который блокирует файл (ы) для вас в другой рабочей копии без вашего ведома (локально или в WC на ​​вашем сервере), или, возможно, у вас есть общий ресурс WebDAV, который вы смонтировали и который открытие там файла (ов), вызывающего создание блокировки.

person alroc    schedule 18.02.2014
comment
Спасибо за быстрый ответ, проверю возможные проблемы, на которые вы указали. Однако я хочу уточнить, что проблема возникает только после того, как я успешно установил блокировку файла. Типичная последовательность действий, приводящих к ошибке, например: lock file.bin - ›modify file.bin -› commit file.bin - ›Ошибка фиксации. - person cmant; 18.02.2014
comment
Я бы спросил, правильно ли ваша рабочая копия записывает блокировку. Что происходит, когда вы запускаете svn status после взятия блокировки? Вы получаете сообщения об ошибках при получении блокировки? - person alroc; 19.02.2014
comment
Я не получаю никаких ошибок, кроме уже заблокированной при фиксации. На сервере у нас есть только trac, который использует репозиторий, мы попробуем отключить его. В любом случае я обнаружил, что ошибка возникает только после обновления (см. Исходное обновление вопроса). - person cmant; 19.02.2014
comment
Это действительно похоже на то, что у вас где-то есть коррупция. Вы запускали svnadmin verify в репозитории и пробовали оформить новую рабочую копию? - person alroc; 19.02.2014

arrow_upward
2
arrow_downward

Я также столкнулся с той же проблемой и обнаружил, что из трех машин на одной из машин я заблокировал файл, из-за чего я также столкнулся с проблемой. Что я сделал, так это снял блокировку с этой машины и продолжил.

OR

Сначала украдите блокировку, а затем приступайте к работе, так как это лучший вариант, предоставляемый SVN.

person LivCool    schedule 04.03.2015

arrow_upward
2
arrow_downward

При использовании IDE JetBrains:

Щелкните правой кнопкой мыши файл, который нужно разблокировать, перейдите в Subversion и нажмите заблокировать.

затем установите флажок украсть существующую блокировку и примените с помощью ОК.

Снова щелкните этот файл правой кнопкой мыши, перейдите в Subversion и нажмите разблокировать.

При использовании командной строки:

заблокировать файл с помощью --force

svn lock --force path/to/file.ext

и разблокировать его снова

svn unlock path/to/file.ext
person klausf    schedule 17.01.2019

arrow_upward
0
arrow_downward

Нашел это: https://groups.google.com/forum/#!topic/subversion_users/wZikmNEubz4 Кажется, эта проблема проявляется при использовании клиента svn 1.8 и сервера до 1.6.17: при обновлении корневой папки рабочей копии мои блокировки нарушаются (независимо от флага блокировки необходимости) .

Я перешел на клиентскую версию 1.7.14, и проблема не возникла.

person cmant    schedule 20.02.2014