Добавление и удаление файлов

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

Чтобы добавить файл в проект, сначала вы должны создать его,  затем использовать команду cvs add, чтобы маркировать его как добавленный. Затем  при следующем выполнении команды cvs commit CVS добавит этот файл в репозиторий.

Например, вот так можно добавить файл README в проект httpc:

$ ls

CVS Makefile httpc.c poll-server

$ vi README

...введите описание httpc...

$ ls

CVS Makefile README httpc.c poll-server

$ cvs update

cvs update: Updating.

? README --- CVS еще не знает об этом файле

$ cvs add README

cvs add: scheduling file `README' for addition

cvs add: use 'cvs commit' to add this file permanently

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

cvs update: 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 update: Updating.

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

retrieving revision 1.8

retrieving revision 1.9

Merging differences between 1.8 and 1.9 into httpc.c

rcsmerge: warning: conflicts during merge

cvs update: conflicts found in httpc.c

C httpc.c

$

В этом случае другой разработчик изменил тот же участок файла,  что и вы, поэтому CVS жалуется на конфликт. Вместо того, чтобы напечатать M  httpc.c, как это обычно происходит, CVS печатает C httpc.c, что означает наличие  конфликта в этом файле.

Чтобы справиться с конфликтом, откройте этот файл в редакторе. CVS обозначает  конфликтующий текст так:

/* Look up the IP address of the host. */

host_info = gethostbyname (hostname);

<<<<<<< httpc.c

if (! host_info)

{

fprintf(stderr, "%s: host not found: %s\n", progname, hostname);

exit(1);

}

=======

if (! host_info)

{

printf("httpc: no host");

exit(1);

}

>>>>>>> 1.9

sock = socket (PF_INET, SOCK_STREAM, 0);

Текст вашего рабочего файла появляется сверху, после символов  <<<. Внизу находится конфликтующий код другого разработчика. Номер  редакции 1.9 указывает, что конфликтующее изменение было внесено в версии 1.9  этого файла, упрощая проверку журнальных записей или просто выяснение изменений  с помощью `cvs diff'.

Когда вы решите, как именно справиться с конфликтом, уберите  маркеры из кода и отредактируйте его. В этом случае, так как ваша обработка  ошибок определенно лучше, то просто отбросьте чужой вариант, оставив такой код:  /* Look up the IP address of the host. */ host_info = gethostbyname (hostname); if (! host_info)

{

fprintf(stderr, "%s: host not found: %s\n", progname, hostname);

exit(1);

}

sock = socket (PF_INET, SOCK_STREAM, 0);

Теперь протестируйте изменения и зафиксируйте их:

$ make

gcc -g -Wall -Wmissing-prototypes -lnsl -lsocket httpc.c -o httpc

$ httpc GET http://www.cyclic.com

HTTP/1.0 200 Document follows

Date: Thu, 31 Oct 1996 23:04:06 GMT

...

$ httpc GET http://www.frobnitz.com

httpc: host not found: www.frobnitz.com

$ cvs commit httpc.c

Важно понимать, что именно CVS считает конфликтом. CVS не  понимает семантики вашей программы, он обращается с исходным кодом просто как с  деревом текстовых файлов. Если один разработчик добавляет новый аргумент в  функцию и исправляет все ее вызовы, пока другой разработчик одновременно  добавляет новый вызов этой функции, и не передает ей этот новый аргумент, что  определенно является конфликтом -- два изменения несовместимы -- но CVS не  сообщит об этом. Его понимание конфликтов строго текстуально.  На практике, однако, конфликты случаются редко. Обычно они  происходят потому, что два человека пытаются справиться с одной и той же  проблемой, от недостатка взаимодействия между разработчиками, или от разногласий  по поводу архитектуры программы. Правильной распределение задач между  разработчиками уменьшает вероятность конфликтов.  Многие системы контроля версий позволяют разработчику  блокировать файл, предотвращая внесение в него изменений до тех пор, пока его  собственные изменения не будут зафиксированы. Несмотря на то, что блокировки  уместны в некоторых ситуациях, это не всегда подход лучше, чем подход CVS.  Изменения обычно объединяются без проблем, а разработчики иногда забывают убрать  блокировку, в обоих случаях явное блокирование приводит к ненужным задержкам.  Более того, блокировки предотвращают только текстуальные конфликты -- они ничего  не могут поделать с семантическими конфликтами типа вышеописанного -- когда два  разработчика редактируют разные файлы.

Footnotes

(1) Интересно, почему это вообще не -u? Прим. перев.

(2) Все же лучше использовать -u. Прим. перев.

Список литературы

Для подготовки данной работы были использованы материалы с сайта http://www.citforum.ru/

Как заставить игру работать быстрее

Автор: Antiloop, Уголок DirectX.

В этой маленькой статье я дам несколько собранных мною советов как сделать ваш программный код для DirectX более быстрым.

Во-первых, если вы хотите работать с DirectX, переходите на VB6. Сама программа шестого бейсика работает быстрее, чем программа пятого (спасибо компилятору). Во-вторых, библиотека седьмого DirectX от Microsoft работает ГОРАЗДО (!) быстрее, чем Patrice Scribe TLB (неполная функциональность это уже отдельный разговор).

Итак, про компилятор вроде бы сказал. Вам не потребуется компилировать всю программу, если вы хотите посмотреть только маленькое изменение, так как делает это Си. Однако сама программа Visual Basic работает во много раз медленнее программы на Си - и опять это заслуга компилятора, ну не может он отучить прогу от родной msvbvm60 библиотеки.:(

Вот некоторые советы, которые помогут вам сделать вашу DirectX игру более быстрой:

Если вы совершаете блиттинг в DirectX с помощью программного драйвера, а не аппаратного ускорения, то используйте функцию BltFast, если вам надо просто перенести спрайт, а не использовать растяжение, вращение и т. п. BltFast работает примерно на 10% быстрее, чем функция Blt, а также и просто удобнее в использовании, потому что вам надо передавать меньше структур.

DirectDraw и Direct3D гораздо быстрее в полноэкранном режиме, чем в оконном

Избегайте очень много операций блиттинга.

Избегайте создания большого количества поверхностей. Не создавайте массивы поверхностей. Старайтесь размещать как можно больше спрайтов на одной поверхности.

Если вы делаете игру с большим количеством спрайтов и/или тайлов, попробуйте размещать их в массивы структур, создавать классы или что-нибудь в этом роде. Таким образом, когда вам надо будет вывести все спрайты, вы можете нарисовать их в один цикл типа этого:

Dim i As Long

For i = 0 To NUM_SPRITES

Call Sprite(i).DoAI

Call Sprite(i).Move

Call Sprite(i).Draw

Next i

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

Избегайте большого количества циклов. Старайтесь сделать как можно больше работы за один цикл.

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

Если вы создаете Direct3D игру, выполните поиск устройства, наиболее подходящего для D3D

Ramp эмуляция всегда лучше RGB эмуляции, однако ни одна из них не сравнится с HAL (Hardware Acceleration Layer - рендеринг через аппаратное ускорение).

В Direct3D Retained Mode при рендеринге большого количества многоугольников без использования HAL используйте Flat shading. Этот эффект гораздо быстрее Gouraud shading.

Без аппаратного ускорения избавляйтесь от эффекта Dithering (сглаживания пикселей). Конечно игра быдет выглядеть с ним лучше, но это очень сильно тормозит программу. Если используете HAL, тогда верните Dithering на место:)

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

Избегайте множества переменных Public и длинных массивов. Они жрут больше стэкового места на протяжении всего сеанса запуска программы и они могут затормозить программу.

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

Список литературы

Для подготовки данной работы были использованы материалы с сайта http://www.citforum.ru/