В команде есть отдел, где у ребят соглашение: сначала налаживать lock на файл а потом его редактировать, и при коммите лок снимается. Это они делают во избежания того чтобы несколько людей изменяли один файл (там у них вполне обоснованный такой use case).
Кто знает возможно ли сделать следующее: при коммите файла проверять, наложил ли данный пользователь lock или нет, и если у него нет лока на этот файл, то отменять коммит? Предпочтительно в Mercurial.

Ну это конечко скорее всего хуками делается, но с ними не приходиось работать и всех их возможностей не знаю.

похоже, что нет
с другой стороны, подобные локи все равно автоматически бы не подтягивались — только после pull'a
хуками, если извернуться, можно сделать так, что при коммите делать pull preview. И в случае, если в пулле идет файл "имя лочимого файла + .lock", то при наличии этого файла в коммите фейлить коммит. но все равно, это обнаружится только в момент коммита. а, значит, кому-то придется переделывать заново работу. 
Мне кажется, можно просто процесс перестроить.
Если это бинарник, и мердж его штатными средствами, ну, совсем-совсем, никак не возможен, то рассылать сообщение. мол, собираюсь работать над тем-то, не трожьте пока что.
Если этот бинарник имеет некую структуру, или же это не бинарник вовсе, но штатный мердж путается из-за сложной и нетипичной структуры текста, то вот еще решение: разбить эту структуру на кучу файлов, которые будут объединяться в процессе билда на CI. В таком случае, частота конфликтов снизится и резолвиться они смогут в автоматическом режиме. Собственно, именно потому, что так проще резолвить, у нас в репозиториях валятеся не один архив с исходниками внутри, а куча отдельных файлов   

в сводном списке систем контроля версий обрати внимание на столбец "Concurrency model"
И у Git'a, и у Mercurial'a там указано "Merge", что говорит об отсутствии штатных средств лока файлов.

какой такой "обоснованный" ?
немного недопонимаю основания....

Добавлено через 1 минуту и 50 секунд

неужели не пользуетесь mq ?

о чем речь?

mercurial queue? ну, положим, в отличие от Гита, не будет привязки к номеру строки. и что? пока один работал над методом, другой отрефакторил весь класс и целевой метод вообще был разбит на два и переименован. как тут поможет поиск контекста? боюсь, в подобном случае, даже лучше, если автопатчинг не пройдет — а то ищи потом логическую ошибку.

skyboy, 

давай сосредоточимся на важном: важно не ответить на вопрос "возможно ли?", а понять нужно ли спрашивать этот вопрос изначально (т.е. понять проблему)

факт жизни: когда над кодом в системе ведения версий работает более чем 0 людей - возникают "конфликты" - ситуации, в которых нужно человеческое вмешательство.
Ранее в централизованных системах без возможности коммитить локально и мержить локально, нужен был механизм оповещения (locking).
этот механизм не решал конфликты. он позволял знать, что конфликты будут, и напр. предлагал приостановить работу (т.е. коммиты!) пока замОк не снят. но сама проблема не решалась: в данный файл мог писАть 1 разработчик, пока не снимет замок. остальные куковали.

в распределенных системах эта проблема решается более удобным и отточенным механизмом слития.
а в git/hg есть возможность вообще избегать слития: можно импортировать свои локальные csы в mq (qimport), тянуть новые изменения (pull -u), а потом одевать свои патчики на обновленное дерево (qpush, qpush, qpush => qfinish)

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


Это сообщение отредактировал(а) bilbobagginz - 15.11.2012, 23:59

bilbobagginz, искренне не понял посыла.
да, так можно.
да, я и сам так делал.
да, без lock'a в данном случае можно обойтись.

skyboy, 
посыл не был кратко описан. а зря, ты прав. Вот он:
Обычно в инструменте, которым пользуются миллионы людей с неодинаковыми требованиями, предусмотрено много чего.
Поэтому, если тебе не хватает какого-то механизма, для достижения которого надо работать (дописывать функционал), и без которого твой рабочий процесс - нарушается, то скорее всего - твой рабочий процесс не доработан или не подходит для работы с этим конкретным инструментом.

bilbobagginz, согласен с тобой: