|
go to the first, previous, next, last section, table of contents.
несколько разработчиков
когда над программным проектом работает более одного человека,
ситуация резко усложняется. зачастую два разработчика одновременно пытаются
редактировать один и тот же файл. одно из решений, известное как
блокировка файлов или блокированное извлечение, -- в
каждый момент времени позволять редактировать файл только одному
человеку. это -- единственное решение при использовании
некоторых систем контроля версий, включая rcs и sccs.
в настоящее время обычным способом совершить блокированное
извлечение рабочей копии с помощью cvs -- использовать
команду во избежание одновременного редактирования файла двумя разработчиками можно также использовать возможность слежения, описанную ниже, вместе с соответствующими административными процедурами (не контролируемыми с помощью программы). модель, используемая в cvs по умолчанию, называется неблокированные извлечения. в этой модели разработчики редактируют свои собственные рабочие копии файла. первый, зафиксировавший свои изменения, не может автоматически узнать, что второй также начал редактировать файл. второй получит сообщения об ошибке, когда попытается зафиксировать файл. он должен использовать соответствующие команды cvs, чтобы его рабочая копия соответствовала свежайшей ревизии, находящейся в репозитории. весь этот процесс проходит почти автоматически. cvs также поддерживает механизмы различных способов коммуникации, никак не настаивая на выполнении каких-либо правил, в отличие от блокированных извлечений. оставшаяся часть главы описывает, как работают все эти различные модели, а также некоторые вопросы, связанные с выбором того или иного варианта. статус файла
основываясь на операциях, которые производятся над извлеченным
файлом, а также на операциях, которые производятся над этим
файлом в репозитории, можно классифицировать несколько состояний
файла. команда
чтобы уточнить состояние файла,
ключи команды
команды $ cvs -n -q update
ключ командной строки `-n' указывает не выполнять
обновление, а просто сообщить о состоянии файлов; `-q' не
печатает имена каждого каталога. прочую информацию о команде
извлечение свежей ревизии файла
если вы хотите получить новую ревизию файла или объединить его с
другой ревизией, используйте команду
ваши изменения в файле не теряются, когда вы используете
например, представим себе, что вы извлекли ревизию 1.4 и начали
редактировать ее. в это время кто-то еще поместил в репозиторий
ревизию 1.5 и, вскорости, ревизию 1.6. если теперь вы выполните
команду
если изменения между ревизиями 1.4 и 1.6 случились слишком близко
к вашим изменениям, происходит пересечение. в таких
случаях на экран выдается предупреждение, а в результирующем
файле оказываются обе версии пересекающихся строк, разделенные
специальными маркерами. see section команда update: обновить рабочий каталог из репозитория, где полностью описана
команда пример конфликтапредположим, что ревизия 1.4 файла `driver.c' содержит такой код:
#include <stdio.h>
void main()
{
parse();
if (nerr == 0)
gencode();
else
fprintf(stderr, "no code generated.\n");
exit(nerr == 0 ? 0 : 1);
}
ревизия 1.6 файла `driver.c' содержит такой код:
#include <stdio.h>
int main(int argc,
char **argv)
{
parse();
if (argc != 1)
{
fprintf(stderr, "tc: no args expected.\n");
exit(1);
}
if (nerr == 0)
gencode();
else
fprintf(stderr, "no code generated.\n");
exit(!!nerr);
}
ваша рабочая копия файла `driver.c', основанная на ревизии 1.4, перед выполнением `cvs update' содержит такой код:
#include <stdlib.h>
#include <stdio.h>
void main()
{
init_scanner();
parse();
if (nerr == 0)
gencode();
else
fprintf(stderr, "no code generated.\n");
exit(nerr == 0 ? exit_success : exit_failure);
}
вы выполняете `cvs update': $ cvs update driver.c rcs file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v retrieving revision 1.4 retrieving revision 1.6 merging differences between 1.4 and 1.6 into driver.c rcsmerge warning: overlaps during merge cvs update: conflicts found in driver.c c driver.c cvs сообщает, что вы встретились с конфликтами. ваш исходный рабочий файл сохранен в `.#driver.c.1.4'. новая версия `driver.c' содержит такой код:
#include <stdlib.h>
#include <stdio.h>
int main(int argc,
char **argv)
{
init_scanner();
parse();
if (argc != 1)
{
fprintf(stderr, "tc: no args expected.\n");
exit(1);
}
if (nerr == 0)
gencode();
else
fprintf(stderr, "no code generated.\n");
<<<<<<< driver.c
exit(nerr == 0 ? exit_success : exit_failure);
=======
exit(!!nerr);
>>>>>>> 1.6
}
заметьте, что непересекающиеся модификации включены в вашу рабочую копию, а пересекающаяся секция четко обозначена строками `<<<<<<<', `=======' and `>>>>>>>'. разрешить конфликт можно, отредактировав файл, удалив маркеры и неверный вариант. предположим, в результате у вас получился такой файл:
#include <stdlib.h>
#include <stdio.h>
int main(int argc,
char **argv)
{
init_scanner();
parse();
if (argc != 1)
{
fprintf(stderr, "tc: no args expected.\n");
exit(1);
}
if (nerr == 0)
gencode();
else
fprintf(stderr, "no code generated.\n");
exit(nerr == 0 ? exit_success : exit_failure);
}
теперь вы можете поместить этот файл в репозиторий в качестве ревизии 1.7. $ cvs commit -m "initialize scanner. use symbolic exit values." driver.c checking in driver.c; /usr/local/cvsroot/yoyodyne/tc/driver.c,v <-- driver.c new revision: 1.7; previous revision: 1.6 done чтобы защитить вас, cvs откажется фиксировать файл, если в нем произошел конфликт и вы с ним не справились. в настоящий момент для разрешения конфликта нужно изменить дату модификации файла. в предыдущих версиях cvs вам также требовалось убедиться, что файл не содержит маркеров конфликта. так как ваш файл действительно может содержать маркеры конфликтов (символы `>>>>>>>>' в начале строки, не обозначающие конфликта), то в текущей версии cvs выдает предупреждение и фиксирует файл.
если вы используете информирование коллег о фиксировании ревизийчасто бывает полезно информировать своих коллег, когда вы фиксируете новую ревизию файла. можно использовать ключ `-i' в файле `modules' или файле `loginfo' для автоматизации этого процесса. see section файл `modules'. see section файл loginfo. можно использовать эти возможности cvs для того, чтобы указать cvs, например, отсылать почтовые сообщения всем разработчикам или помещать сообщение в локальную группу новостей. совместный доступ нескольких разработчиков к cvsесли несколько разработчиков попытаются одновременно выполнить cvs, один из них получит такое сообщение: [11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo cvs попытается повторить операцию каждые 30 секунд, и либо успешно выполнит ее, либо опять напечатает сообщение, если опять нужно ждать. если блокировка сохраняется слишком долго, найдите того, кто создал ее и спросите его, что за команду он выполняет. если он не выполняет команд cvs, загляните в каталог репозитория, упомянутый в сообщении, и удалите файлы, чьи имена начинаются с `#cvs.rfl', `#cvs.wfl', или `#cvs.lock', принадлежащие указанному пользователю. заметьте, что эти блокировки предназначаются для защиты внутренних структур данных cvs и не имеют никакого отношения к слову блокировка в том смысле, который используется в rcs и означает блокированные извлечения (see section несколько разработчиков). неограниченное количество пользователей может одновременно читать репозиторий; только когда кто-либо пишет туда, блокировки препятствуют прочим как читать, так и писать. можно было бы надеяться, что верно следующее утверждение:
если кто-либо фиксирует несколько изменений одной командой
cvs, то команда
к сожалению, при работе с cvs это утверждение неверно. например, если имеются файлы a/one.c a/two.c b/three.c b/four.c и кто-то выполняет cvs ci a/two.c b/three.c
а затем кто-то еще в то же самое время выполняет как отследить, кто редактирует файлы?для большинства групп использования cvs в режиме по умолчанию совершенно достаточно. пользователи иногда могут, попытавшись зафиксировать изменение, обнаружить, что мешает другое изменение, но они справятся с этим и все же зафиксируют свое изменение. в других группах предпочитают знать, кто какие файлы редактирует, так что если два человека захотят редактировать один и тот же файл, то они предпочтут договориться друг с другом, кто что будет делать, чтобы не получать проблем при каждом фиксировании. возможности, описанные в этой главе, помогают такой координации, сохраняя возможность редактирования одного файла двум разработчикам одновременно.
для получения максимального преимущества разработчики должны
использовать как с помощью cvs следить за определенными файлами?для того, чтобы включить использование функции слежения, сначала укажите, за какими файлами нужно следить.
cvs может посылать вам уведомления
вы можете сказать cvs, что хотели бы получать уведомления о
разнообразных действиях, совершенных с файлом. в принципе вы
можете сделать это без использования
когда требуется отправить уведомление, cvs обращается к административному файлу `notify'. этот файл можно отредактировать точно так же, как и другие административные файл (see section административные файлы). синтаксис этого файла подобен другим административным файлам (see section обычный синтаксис), где каждая строка состоит из регулярного выражения и команды, которую надо выполнить. команда должна содержать одно единственное упоминание символов `%s', которые будут заменены на имя пользователя, которого нужно уведомить; остальная информация передается этой команде на стандартный вход. обычно в файл `notify' помещается такая строка: all mail %s -s \"cvs notification\" в результате всего этого пользователи получают уведомления по электронной почте. заметьте, что если вы настроите все именно так, как рассказано выше, то пользователи будут получать уведомления на сервере. конечно же, можно написать скрипт `notify', который перенаправляет уведомления на другой адрес, но, для простоты, cvs позволяет задать адрес, по которому следует отсылать уведомления пользователю. для этого создайте в `cvsroot' файл `users', в котором каждая строка имеет вид пользователь:адрес. тогда вместо того, чтобы использовать имя пользователя, cvs будет использовать адрес. cvs не уведомляет вас о ваших собственных изменениях. в настоящий момент проверка производится, основываясь на имени пользователя, который совершает действия, приводящие к отсылке уведомления. вообще, функция слежения каждый раз сообщает только об одном изменении, сделанном одним пользователем. вероятно, было бы более полезно, если бы отдельно отслеживались целые рабочие каталоги, поэтому такое поведение было бы полезно изменить. как редактировать файлы, за которыми наблюдают?
так как файл, за которым следит кто-либо, извлекается в режиме
только для чтения, то вы не можете просто взять и отредактировать
его. для того, чтобы сделать его доступным для записи и сообщить
остальным, что вы планируете отредактировать этот файл,
используйте команду
обычно, когда вы закончите редактирование файлов, используйте
команду
при использовании сетевого cvs вы можете использовать
команды информация о том, кто следит и кто редактирует
использование слежений со старыми версиями cvsесли вы используете возможность слежения за репозиторием, то в нем создаются каталоги `cvs/', в которых хранится информация о слежениях за файлами из соответствующего каталога. если вы попытаетесь использовать в этом репозитории cvs версии 1.6 и ранее, вы получите такое сообщение об ошибке: cvs update: cannot open cvs/entries for reading: no such file or directory
выполняемая команда, скорее всего, будет прервана. для
использования возможности слежения обновите все копии cvs,
которые используют этот репозиторий в локальном или серверном
режиме. если вы не можете совершить обновление, используйте
команды выбор между блокированными и неблокированными извлечениямиблокированные и неблокированные извлечения имеют свои "за" и "против". достаточно сказать, что это в основном вопрос мнения, или же принятого в группе стиле работы. впрочем же, вот краткое описание некоторых возникающих вопросов. существует множество способов организовать команду разработчиков. cvs не пытается насильно внедрить какой-либо способ. cvs -- это просто инструмент, который можно использовать различными способами. блокированные извлечения могут оказывать отрицательное влияние на производительность. если два человека хотят отредактировать различные части файла, какие могут быть причины помешать кому-нибудь из них сделать это? обычным делом также является заблокировать файл, предполагая поредактировать его, а затем забыть снять блокировку. люди, обычно те, кто хорошо знаком с блокированными извлечениями, обычно спрашивают, как часто случаются конфликты при использовании неблокированных извлечений, и сколь сложно их разрешить. опыт разнообразных групп показал, что такие конфликты случаются редко и обычно их можно разрешить относительно спокойно. редкость серьёзных конфликтов может удивить, пока не осознаешь, что они случаются только когда два разработчика расходятся во мнениях о должном дизайне определенного куска кода; такое расхождение свидетельствует о том, что команда, прежде всего, не общалась друг с другом должным образом. для того, чтобы сотрудничать в условиях любой системы контроля исходных текстов, разработчики должны не иметь разногласий по поводу общего дизайна системы; при отсутствии таковых, пересекающиеся изменения обычно разрешаются напрямую. в некоторых случаях неблокированные извлечения совершенно точно являются неподходящими. если для файлов, которые вы редактируете, не существует инструмента для слияния (например, файлы, созданные текстовым процессором, или же файлы, созданные с помощью cad-системы), а переход на программу, которая использует формат файлов с возможностью слияния, нежелателен, то разрешение конфликтов, скорее всего, будет столь неприятным, что будет проще избежать их, используя блокированные извлечения. возможность слежения, описанная выше, в главе section как отследить, кто редактирует файлы?, может считаться промежуточной моделью между блокированными и неблокированными изменениями. когда вы редактируете файл, можно узнать, кто ещё редактирует его. система, вместо того, чтобы просто запретить двум людям редактировать файл, может описать ситуацию и позволить вам самому решить, является ли этот конкретный случай проблемой или нет. таким образом, для некоторых групп механизм слежения может считаться объединением лучших черт блокированных и неблокированных изменений. go to the first, previous, next, last section, table of contents. |