| -F file] [-r revision]
[files...]
Команда commit используется, чтобы внести изменения, произвед©нные в рабочем каталоге, в основное хранилище.
Если вы не определили конкретный файл или группу файлов, то система CVS будет проверять все файлы в рабочем каталоге, выясняя изменились ли они. commit проверяет файлы весьма тщательно и делает изменения в хранилище лишь в случае реального изменения содержимого файла, а не просто даты создания. По умолчанию, или явным указанием параметра -R будут проверяться все подкаталоги рабочего каталога. Вы можете ограничить область действия команды commit лишь текущим каталогом, использовав параметр -l.
Если содержимое файла не изменилось, то commit сообщает об этом и ничего не изменяет. Если commit обнаруживает, что необходимо выполнить команду update, то вам будет сообщено об этом, но не будет никакого автоматического вызова update. Предполагается, что вы лучше знаете, когда следует выполнять команду update.
Когда все нормально завершилось, вызывается редактор текста, чтобы вы могли ввести какие-то комментарии к данной операции commit. Комментарии будут переданы одной или больше протокольных программ, которые запишут эти комментарии в файл RCS внутри хранилища. Эти комментарии могут быть найдены позже с помощью команды log. Короткий комментарий может быть определ©н в командной строке с помощью параметра -m message, тогда редактор не будет вызываться. Если вы хотите записать относительно длинный комментарий и, одновременно, избежать вызова редактора текста, можно использовать параметр -F file. Комментарий будет взят из файла с именем file.
Кроме вышеперечисленных, команда commit поддерживает следующие параметры.
Вы можете выполнить commit для версии в ветви (содержит четное число разделительных точек) с использованием параметра -r. Чтобы создать версию ветви используйте параметр -b в командах tag или rtag. После этого вы сможете, использовав команды update или checkout, привести в соответствие состояние вашего рабочего каталога и вновь образованной версии в ветви, не разрушив ваши исходные тексты в основном стволе разработки. Например, вам необходимо создать заплату (исправление) вашего продукта версии 1.2, хотя вовсю ид©т разработка варианта 2.0. Сделать это можно следующим образом.
cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module cvs checkout -r FCS1_2_Patch product_module cd product_module [[ hack away ]] cvs commitЭто действует автоматически поскольку параметр -r является липким.
Скажем вы работали над экспериментальным программным обеспечением, которое базировалось на какой-то версии, которую вы взяли в рабочий каталог (выполнили checkout) на прошлой неделе. Если другие разработчики тоже работают с теми же версиями исходных текстов, то чтобы не портить основной поток разработки, вы могли бы записать ваши варианты экспериментальные в отдельную новую ветвь. Другие разработчики, смогут использовать ваши экспериментальные наработки и, одновременно, целиком использовать мощь CVS в отношении разрешения конфликтов. Сценарий мог бы быть таким.
[[ hacked sources are present ]]
$ cvs tag -b EXPR1
$ cvs update -r EXPR1
$ cvs commit
Команда update сделает параметр -r EXPR1 липким для всех
файлов.
Заметим, что ваши изменения в файлах никогда не будут удалены командой
update. Команда commit будет автоматически работать с верной
ветвью, поскольку параметр -r - липкий.
Вы также можете делать так:
[[ hacked sources are present ]]
$ cvs tag -b EXPR1
$ cvs commit -r EXPR1
но тогда, только измен©нные вами файлы станут липкими. Если вы убер©те
изменения и выполните commit без указания параметра -r EXPR1,
то некоторые файлы неожиданно для вас могут попасть в основной ствол.
Другие разработчики могут использовать ваши экспериментальные наработки,
если выполнят команду:
cvs checkout -r EXPR1 whatever_module