Предыдущая страница реферата | 2  3  4  5  6  7  8  9  10  11  12 | Следующая страница реферата

$ cvs update --- что же теперь думает CVS?

cvs up Updating .

A README --- Файл помечен как добавленный

$ cvs commit README

... CVS просит вас ввести журнальную запись...

RCS file: /u/jimb/cvs-class/rep/httpc/README,v

done

Checking in README;

/u/src/master/httpc/README,v <-- README

initial revision: 1.1

done

$

CVS обращается с удаленными файлами почти так же. Если вы  удалите файл и выполните `cvs update', CVS не считает, что вы намереваетесь  удалить файл из проекта. Вместо этого он поступает милосерднее -- он  восстанавливает последнюю сохраненную в репозитории версию файла и маркирует его  флагом U, точно так же, как и любой другое обновление. (Это означает, что если  вы хотите отменить изменения файла в рабочем каталоге, вы можете просто удалить  его и позволить команде `cvs update' создать его заново.)

Чтобы удалить файл из проекта, вы должны сначала удалить его,а  потом использовать команду `cvs rm', чтобы пометить его для удаления. При  следующем запуске команда `cvs commit' удалит файл из репозитория.  Фиксирование файла, маркированного с помощью `cvs rm' не  уничтожает историю этого файла -- к ней просто добавляется еще одна редакция ---  "не существует". В репозитории по прежнему хранятся все записи об этом файле, и  к ним можно обращаться по желанию -- например, с помощью `cvs diff' или `cvs  log'.

Для переименования файла существует несколько стратегий; самая  простая --- переименовать файл в рабочем каталоге, затем выполнить `cvs rm' со  старым именем и `cvs add' с новым. Недостаток этого подхода в том, что  журнальные записи о содержимом старого файла не переносятся в новый файл. Другие  стратегии позволяют избежать этого, но зато доставляют другие, более странные  проблемы.

Вы можете добавлять каталоги точно также, как и обычные файлы.

Написание хороших журнальных записей Если можно использовать `cvs diff', чтобы получить точное содержание любого изменения, то зачем тогда придумывать еще журнальную запись о нем? Очевидно, что журнальные записи короче, чем тексты изменений, и позволяют читателю получить общее понимание изменения без необходимости углубляться в детали.

Однако же, хорошая запись в журнале описывает причину, по которой было сделано изменение. Например, плохая журнальная запись для редакции 1.7 может звучать как "Преобразовать `t' к нижнему регистру". Это правильно, но бесполезно - `cvs diff' предоставляет точно ту же информацию, и гораздо яснее. Гораздо лучшей журнальной записью было бы "Сделать эту проверку независящей от регистра", потому что это гораздо яснее описывает причину любому, кто понимает, что происходит в коде - клиенты HTTP должны игнорировать регистр букв при анализе заголовков ответа от сервера.

Обработка конфликтов Как уже упоминалось, команда `cvs update' объединяет изменения, сделанные другими разработчиками, с исходными текстами в вашем рабочем каталоге. Если вы отредактировали файл одновременно с кем-то другим, CVS объединит ваши изменения.

Довольно легко представить себе, как работает объединение, если изменения были совершены в разных участках файла, но что если вы оба изменили одну и ту же строку? CVS называет эту ситуацию конфликт и предоставляет вам самому разобраться с ним.

Например, предположим, что вы добавили некую проверку на ошибки в код, определяющий адрес сервера. Перед фиксированием изменений вы должны запустить `cvs update', чтобы синхронизировать ваш рабочий каталог с репозиторием:

$ cvs update

cvs up Updating .

RCS file: /u/src/master/httpc/httpc.c,v

retrieving revision 1.8

Рекомендуем скачать другие рефераты по теме: экономический диплом, банк курсовых.



Предыдущая страница реферата | 2  3  4  5  6  7  8  9  10  11  12 | Следующая страница реферата

Поделитесь этой записью или добавьте в закладки