Создание собственного проекта с открытым исходным кодом на портале CodePlex

МИНИСТЕРСТВО  ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ  БЮДЖЕТНОЕ 

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО

ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«Омский государственный  технический университет»

 

Кафедра «Прикладная математика и фундаментальная информатика»

Специальность 010400.62 – «Информационные технологии»

 

 

 

 

 

КУРСОВОЙ  ПРОЕКТ

 

на тему: «Создание собственного проекта с открытым исходным кодом на портале CodePlex»

по дисциплине «Операционные системы»

Студент Ковалев  Денис Викторович группы ИТ-319

 

Пояснительная записка

 

Шифр работы:

КП – 206899 – 56 – 05 – 00.00.000.ПЗ

 

Руководитель  работы

Свалов А. А.

___________________________

^{(подпись,  дата)}

Разработал  студент

Ковалев Д. В.

___________________________

^{(подпись,  дата)}

Оценка____________________

 

 

Омск 2012

Аннотация

 

Отчет по курсовому проекту 27 с., 8 рис., 7 источников.

СИСТЕМА УПРАВЛЕНИЯ ВЕРСИЯМИ, CODEPLEX, MERCURIAL, TORTOISEHG, C#

Цель работы – создание собственного проекта с открытым исходным кодом на портале CodePlex.

Объектом исследования данной работы является язык программирования C#, системы управления версиями, а также порта codeplex.com.

В ходе работы проводились:

• создание проекта на C# с дальнейшей публикацией на CodePlex;
• изучение аспектов системы управления версиями CodePlex.

В результате проведения данной работы был создан проект на C#, который был опубликован с открытым исходным кодом на портале CodePlex.

 

Содержание

 

 

Введение

 

Компьютерный мир за последние  десятилетия достиг ошеломляющих результатов. Ни одна из отраслей не достигла таких результатов в техническом прогрессе, как компьютерная. Изменения, которые за 15 лет привели к появлению такого компьютерного продукта, как Windows, поистине впечатляют.

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

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

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

Одной из преуспевающих систем контроля версий является новый онлайновый сервис от разработчиков Microsoft, получивший название CodePlex.

 

1 Постановка задачи курсового проектирования

 

Целью проекта  является разработка приложения для определения прогноза ЛД₅₀ по исходным данным на языке C#. Данная программа будет оснащена настраиваемым удобным пользовательским интерфейсом, все данные будут приведены в виде графиков, описаний текущих состояний.

Данная программа будет  иметь 3 способа определения летальной дозы ЛД₁₀₀:

• по заданным значениям;
• линейная аппроксимация по двум точкам;
• регрессия (неточный прогноз).

Данный проект должен быть создан под управлением  системы контроля, то есть под системой управления версиями CodePlex.

Такие системы наиболее широко используются при разработке программного обеспечения для хранения исходных кодов, разрабатываемой программы. Однако они могут с успехом применяться и в других областях, в которых ведётся работа с большим количеством непрерывно изменяющихся электронных документов. В частности, системы управления версиями применяются в САПР, обычно в составе систем управления данными об изделии (PDM). Управление версиями используется в инструментах конфигурационного управления (Software Configuration Management Tools).

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

2 Теоретический анализ

 

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

2.1 Общие сведения

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

Традиционные системы управления версиями используют централизованную модель, когда имеется единое хранилище  документов, управляемое специальным сервером, который и выполняет большую часть функций по управлению версиями. Пользователь, работающий с документами, должен сначала получить нужную ему версию документа из хранилища; обычно создаётся локальная копия документа, т. н. «рабочая копия». Может быть получена последняя версия или любая из предыдущих, которая может быть выбрана по номеру версии или дате создания, иногда и по другим признакам. После того, как в документ внесены нужные изменения, новая версия помещается в хранилище. В отличие от простого сохранения файла, предыдущая версия не стирается, а тоже остаётся в хранилище и может быть оттуда получена в любое время. Сервер может использовать т. н. дельта-компрессию — такой способ хранения документов, при котором сохраняются только изменения между последовательными версиями, что позволяет уменьшить объём хранимых данных. Поскольку обычно наиболее востребованной является последняя версия файла, система может при сохранении новой версии сохранять её целиком, заменяя в хранилище последнюю ранее сохранённую версию на разницу между этой и последней версией. Некоторые системы (например, ClearCase) поддерживают сохранение версий обоих видов: большинство версий сохраняется в виде дельт, но периодически (по специальной команде администратора) выполняется сохранение версий всех файлов в полном виде; такой подход обеспечивает максимально полное восстановление истории в случае повреждения репозитория.

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

Часто бывает, что над одним проектом одновременно работают несколько человек. Если два человека изменяют один и тот же файл, то один из них может случайно отменить изменения, сделанные другим. Системы управления версиями отслеживают такие конфликты и предлагают средства их решения. Большинство систем может автоматически объединить (слить) изменения, сделанные разными разработчиками. Однако такое автоматическое объединение изменений, обычно, возможно только для текстовых файлов и при условии, что изменялись разные (непересекающиеся) части этого файла. Такое ограничение связано с тем, что большинство систем управления версиями ориентированы на поддержку процесса разработки программного обеспечения, а исходные коды программ хранятся в текстовых файлах. Если автоматическое объединение выполнить не удалось, система может предложить решить проблему вручную.

Часто выполнить слияние невозможно ни в автоматическом, ни в ручном режиме, например, если формат файла неизвестен или слишком сложен. Некоторые системы управления версиями дают возможность заблокировать файл в хранилище. Блокировка не позволяет другим пользователям получить рабочую копию или препятствует изменению рабочей копии файла (например, средствами файловой системы) и обеспечивает, таким образом, исключительный доступ только тому пользователю, который работает с документом.

Многие системы управления версиями предоставляют ряд других возможностей:

• позволяют создавать разные варианты одного документа, т. н. ветки, с общей историей изменений до точки ветвления и с разными — после неё;
• дают возможность узнать, кто и когда добавил или изменил конкретный набор строк в файле;
• ведут журнал изменений, в который пользователи могут записывать пояснения о том, что и почему они изменили в данной версии;
• контролируют права доступа пользователей, разрешая или запрещая чтение или изменение данных, в зависимости от того, кто запрашивает это действие.

2.2 Типичный порядок работы с системой

Каждая система управления версиями имеет свои специфические особенности  в наборе команд, порядке работы пользователей и администрировании. Тем не менее, общий порядок работы для большинства VCS совершенно стереотипен. Здесь предполагается, что проект, каким бы он ни был, уже существует и на сервере размещён его репозиторий, к которому разработчик получает доступ.

2.2.1 Начало работы с проектом

Первым действием, которое должен выполнить разработчик, является извлечение рабочей копии проекта или той его части, с которой предстоит работать. Это действие выполняется с помощью стандартной команды извлечения версии (clone²) либо специальной команды, фактически выполняющей то же самое действие. Разработчик задаёт версию, которая должна быть скопирована, по умолчанию обычно копируется последняя (или выбранная администратором в качестве основной) версия.

По команде извлечения устанавливается  соединение с сервером и проект (или его часть — один из каталогов с подкаталогами) в виде дерева каталогов и файлов копируется на компьютер разработчика. Обычной практикой является дублирование рабочей копии: помимо основного каталога с проектом на локальный диск (либо в отдельный, специально выбранный каталог, либо в системные подкаталоги основного дерева проекта) дополнительно записывается ещё одна его копия. Работая с проектом, разработчик изменяет только файлы основной рабочей копии. Вторая локальная копия хранится в качестве эталона, позволяя в любой момент без обращения к серверу определить, какие изменения внесены в конкретный файл или проект в целом и от какой версии была «отпочкована» рабочая копия; как правило, любая попытка ручного изменения этой копии приводит к ошибкам в работе программного обеспечения VCS.

2.2.2 Ежедневный цикл работы

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

2.2.2.1 Обновление рабочей копии

По мере внесения изменений в  проект рабочая копия на компьютере разработчика стареет, расхождение  её с основной версией проекта  увеличивается. Это повышает риск возникновения конфликтных изменений. Поэтому удобно поддерживать рабочую копию в состоянии, максимально близком к текущей основной версии, для чего разработчик выполняет операцию обновления рабочей копии (update³) насколько возможно часто (реальная частота обновлений определяется частотой внесения изменений, зависящей от активности разработки и числа разработчиков, а также временем, затрачиваемым на каждое обновление — если оно велико, разработчик вынужден ограничивать частоту обновлений, чтобы не терять время).

2.2.2.2 Модификация проекта

Разработчик модифицирует проект, изменяя  входящие в него файлы в рабочей  копии в соответствии с проектным  заданием. Эта работа производится локально и не требует обращений  к серверу VCS.

2.2.2.3 Фиксация изменений

Завершив очередной этап работы над заданием, разработчик фиксирует (commit⁴) свои изменения, передавая их на сервер (либо в основную ветвь, если работа над заданием полностью завершена, либо в отдельную ветвь разработки данного задания). VCS может требовать от разработчика перед фиксацией обязательно выполнить обновление рабочей копии. При наличии в системе поддержки отложенных изменений (shelving⁵) изменения могут быть переданы на сервер без фиксации. Если утверждённая политика работы в VCS это позволяет, то фиксация изменений может проводиться не ежедневно, а только по завершении работы над заданием; в этом случае до завершения работы все связанные с заданием изменения сохраняются только в локальной рабочей копии разработчика.

2.2.3 Ветвления

Делать мелкие исправления в проекте можно путём непосредственной правки рабочей копии и последующей фиксацией изменений прямо в главной ветви (стволе) на сервере. Однако при выполнении сколько-нибудь значительных по объёму работ такой порядок становится неудобным: отсутствие фиксации промежуточных изменений на сервере не позволяет работать над чем-либо в групповом режиме, кроме того, повышается риск потери изменений при локальных авариях и теряется возможность анализа и возврата к предыдущим вариантам кода в пределах данной работы. Поэтому для таких изменений обычной практикой является создание ветвей (branch⁶), то есть «отпочковывания» от ствола в какой-то версии нового варианта проекта или его части, разработка в котором ведётся параллельно с изменениями в основной версии. Ветвь создаётся специальной командой. Рабочая копия ветви может быть создана заново обычным образом (командой извлечения рабочей копии, с указанием адреса или идентификатора ветви), либо путём переключения имеющейся рабочей копии на заданную ветвь.

Базовый рабочий цикл при использовании  ветвей остаётся точно таким же, как и в общем случае: разработчик  периодически обновляет рабочую  копию (если с ветвью работает более  одного человека) и фиксирует в  ней свою ежедневную работу. Иногда ветвь разработки так и остаётся самостоятельной (когда изменения порождают новый вариант проекта, который далее развивается отдельно от основного), но чаще всего, когда работа, для которой создана ветвь, выполнена, ветвь реинтегрируется в ствол (основную ветвь). Это может делаться командой слияния (merge⁷), либо путём создания патча, содержащего внесённые в ходе разработки ветви изменения и применения этого патча к текущей основной версии проекта.

2.2.4 Слияние версий

Три вида операций, выполняемых в системе управления версиями, могут приводить к необходимости объединения изменений. Это:

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

Во всех случаях ситуация принципиально  одинакова и имеет следующие  характерные черты:

• ранее была сделана копия дерева файлов и каталогов репозитория или его части.
• впоследствии и в оригинальное дерево и в копию были независимо внесены некоторые изменения.
• требуется объединить изменения в оригинале и копии таким образом, чтобы не нарушить логическую связность проекта и не потерять данные.