C/C++ Как применить технологию SVN к немаленькому проекту?

[jur]

Привет!

"Партия и правительство учат нас" (TM), что при разработке больших проектов следует применять технологию SVN. Сервер, хранилище и все такое. Я попробовал почитать, что это за весчь и с чем ее едят. Общий принцип понятен. Но, к сожалению, практические примеры ограничиваются примерно следующим:

1. Программист Дормидонт исправляет файл Foo1.cpp проекта Main.
2. Программистка Евангелина исправляет файл Foo2.cpp проекта Main.
3. Все оба счастливо субмиттуют свои исправления и проект из 3-х файлов успешно компилируется (третий файл, как вы догадались, Main.cpp).
4. Работа выполнена, "всем пить спирт!" (C) М.Жванецкий.

ОК, более-менее понятно. Но радужное настроение пропадает, когда начинаешь обдумывать ситуацию с проектом, в котором ~80-90 отдельных модулей. Общее число файлов *.CPP и *.H приближается к 2000. Сейчас каждый модуль представляет собой отдельную DLL-ку, которая сопровождается независимо от других. Ее можно править/корректировать/ изменять отдельно, и ни на другие модули это не влияет (конечно, при условии, что ее интерфейс остался прежним).

Но - каменный век. Как такие задачи решаются в правильной парадигме? Как может выглядеть порядок действий на рабочей станции, где понадобилось внести исправление в какой-то из модулей? (Тут же, черт подери, нужно еще помнить целый ряд дополнительных файлов, начиная с *.SLN и *.VCPROJ...)

P.S. Да, забыл сказать, работа ведется в Визуальной Студии (2008), под Виндой (каноническая XP).

[Kivals]

SVN ничего не знает про структуру и алгоритмы - она просто работает с файлами (текстовыми и бинарными). Если ты укажешь поместить в хранилище (получить из хранилища) некий каталог - она проанализирует какие были изменения и обменяется только изменениями.

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

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

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

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

Для Винды есть приятная визуализация - TortoiseSVN

[jur]

SVN ничего не знает про структуру и алгоритмы - она просто работает с файлами (текстовыми и бинарными). Если ты укажешь поместить в хранилище (получить из хранилища) некий каталог - она проанализирует какие были изменения и обменяется только изменениями.

Да, вот это-то меня и смущает, уважаемый коллега! Получается, что нужно хранить только необходимые для перекомпиляции файлы. Иначе через пол-года никаких винчестеров не хватит...

Для полноты картины я обрисую нынешнюю технологию, которой мы пользуемся.

Каждый модуль компилируется локально. В событии Студии "VCPostBuildEventTool" указана команда"copy_to_common_debug.bat $(TargetName)" (или "...release..."). Этот самый "common" - расшаренный диск Z:\ на общем сервере. В *.bat файле копируются 4 файла: *.h, *.dll, *.lib и *.pdb. Для главного исполняемого файла: *.exe и *.pdb. Когда нужно отлаживать проект, идем в рабочую директорию, выполняем *.bat файл, копирующий сюда все нужное из диска Z:\, и запускаем/отлаживаем.

Ну и время от времени мы делаем snapshot, архивируя каталоги всех модулей с помощью замечательного 7z.

Для Винды есть приятная визуализация - TortoiseSVN

Да, большое спасибо, я уже познакомился с этой программой. Более того, мы уже используем эту технологию для работы с отдельно взятыми проектами для ПЛИС Altera, на котрой мы строим свой прибор.

Но вот как все это дело применить для ПО - пока теряюсь... И вообще, нужно-ли заморачиваться с этим SVN для основного проекта программы прибора?... Может кроме дополнительной головной боли от этого SVN-а мы ничего полезного не получим?...

[Dale]

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

Что именно читали? Могу порекомендовать пару достойных книг:

1. https://forum.shelek.ru/index.php/topic,26526.msg254406.html#msg254406 - не только описывает саму клиентскую программу, но и дает ряд ценных рекомендаций по организации структуры проекта и принципам работы с версиями.

2. https://forum.shelek.ru/index.php/topic,26526.msg291554.html#msg291554 - классическая монография по дисциплине управления конфигурациями в целом. Приводится масса полезных паттернов.

P.S. Да, забыл сказать, работа ведется в Визуальной Студии (2008), под Виндой (каноническая XP).

Эти детали не имеют большого значения, стратегия управления конфигурациями от этого не зависит.

[Dale]

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

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

нужно-ли заморачиваться с этим SVN для основного проекта программы прибора?... Может кроме дополнительной головной боли от этого SVN-а мы ничего полезного не получим?...

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

[jur]

Что именно читали? Могу порекомендовать пару достойных книг:
1. https://forum.shelek.ru/index.php/topic,26526.msg254406.html#msg254406 - не только описывает саму клиентскую программу, но и дает ряд ценных рекомендаций по организации структуры проекта и принципам работы с версиями.
2. https://forum.shelek.ru/index.php/topic,26526.msg291554.html#msg291554 - классическая монография по дисциплине управления конфигурациями в целом. Приводится масса полезных паттернов.

Большое спасибо! Почитаю на эту важную тему.

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

Хм... Ну я не знаю... Если с каждой коррекцией будут сохраняться необходимые *.dll и *.pdb (не считая более жмущихся), то место будет расходоваться весьма стремительно. В противном случае, наверное придется всякий раз перекомпилировать все целиком, когда кто-то что-то закомиттил. Не так?

нужно-ли заморачиваться с этим SVN для основного проекта программы прибора?... Может кроме дополнительной головной боли от этого SVN-а мы ничего полезного не получим?...

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

Так вот я как раз и хочу разобраться, нужно ли? :-)

[Dale]

Если с каждой коррекцией будут сохраняться необходимые *.dll и *.pdb (не считая более жмущихся), то место будет расходоваться весьма стремительно.

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

В противном случае, наверное придется всякий раз перекомпилировать все целиком, когда кто-то что-то закомиттил. Не так?

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

Главное - пользоваться правильно настроенным сборщиком проекта (Make, Ant, Rake, MsBuild или что там Ваша команда использует в работе).

Так вот я как раз и хочу разобраться, нужно ли?

Без правильных инструментов обходиться не нужно, конечно. Особенно если они за них не приходится платить. SVN - один из таких инструментов (есть и другие, не менее нужные).

[jur]

Если с каждой коррекцией будут сохраняться необходимые *.dll и *.pdb (не считая более жмущихся), то место будет расходоваться весьма стремительно.

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

Вот, вот! Как раз это меня и интересует! Я, естественно, еще не успел прочитать рекомендованную литературу, но хотел спросить: как сделать так, чтобы перекомпилировать только отдельные, изменившиеся фрагменты всего проекта? По сути, именно это мне, видимо, и нужно. И потом, как обеспечить хранение/загрузку тех модулей, перекомпилировать которые не обязательно (если они не изменялись)?

В противном случае, наверное придется всякий раз перекомпилировать все целиком, когда кто-то что-то закомиттил. Не так?

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

Главное - пользоваться правильно настроенным сборщиком проекта (Make, Ant, Rake, MsBuild или что там Ваша команда использует в работе).

Это, наверное, можно автоматизировать? Или мне придется вручную компилировать только изменившиеся модули? Сейчас я пользуюсь просто devenv.exe из Студии. Лучше воспользоваться чем-то другим?

Без правильных инструментов обходиться не нужно, конечно. Особенно если они за них не приходится платить. SVN - один из таких инструментов (есть и другие, не менее нужные).

Именно! Поэтому я и поднял эту туманную для меня тему :-)

[Dale]

хотел спросить: как сделать так, чтобы перекомпилировать только отдельные, изменившиеся фрагменты всего проекта? По сути, именно это мне, видимо, и нужно.

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

Например, foo.c включает заголовок foo.h, а также заголовок другого модуля bar.h, сервисом которого он пользуется; следовательно, при изменении любого из этих трех файлов foo.c обязательно следует перекомпилировать. Точно так же файл .exe следует перекомпоновать заново, если изменился хотя бы один из образующих его объектных файлов. Таким образом, для каждого проекта строится дерево зависимостей, позволяющее определить минимально необходимый объем работы по актуализации внесенных изменений.

И потом, как обеспечить хранение/загрузку тех модулей, перекомпилировать которые не обязательно (если они не изменялись)?

Это происходит само собой. Например, после предыдущей компиляции исходного файла foo.c в рабочей директории остался объектный файл foo.obj, если Вы не удалили его нарочно. Если при очередной сборке проекта выяснится, что исходный файл не менялся, при компоновке будет использован тот самый объектный файл, поскольку он не нуждается в перестроении заново. Если же вдруг выяснится, что он был удален, сборщик построит его заново.

Это, наверное, можно автоматизировать? Или мне придется вручную компилировать только изменившиеся модули? Сейчас я пользуюсь просто devenv.exe из Студии. Лучше воспользоваться чем-то другим?

Это необходимо автоматизировать. Разработчик не должен тратить время на подобную рутину, его время слишком дорого стоит.

Во-первых, сама Visual Studio умеет строить проекты. Однако, если Вы всерьез решили наводить порядок в процессах разработки, очень скоро наступит момент, когда Вы захотите строить проект без участия человека (например, в ночное время по расписанию; это вовсе не бессмысленная затея, как может поначалу показаться). Для этого потребуется соответствующий инструмент.

Прежде всего, MsBuild, благо он входит в поставку VS. Он способен собрать самый сложный проект одной командой. Достоинство - он "родной" для Студии, поэтому легче всего интегрируется. Недостаток вытекает из достоинства - не лучший вариант для других видов проектов, кроме Студийных, не говоря об отсутствии кроссплатформенности. Я сам им пользуюсь на работе.

Затем Make - это классика жанра, реализован на всех платформах. Недостатки - сценарии построения пишутся на довольно сложном и громоздком языке, при этом они не слишком гибки. Примеры можете посмотреть в моих статьях https://club.shelek.ru/viewart.php?id=357 и https://club.shelek.ru/viewart.php?id=358

Сейчас для разработки своих встроенных приложений я использую Rake - более современный вариант Make, написанный на языке Ruby. Он позволил решить проблемы, возникавшие с предыдущими инструментами. Но начинать с него не рекомендую.

Именно! Поэтому я и поднял эту туманную для меня тему

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

[jur]

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

Полагаю, что со временем у меня, как у всякого новичка, появятся новые вопросы. Тогда я еще поспрошаю, хорошо?

Спасибо!

[Dale]

начал осознавать, насколько это все сложно, запутанно и непонятно

На самом деле там все просто и логично.

Нужно только подобрать правильные книги. Тогда после их прочтения непонятным останется только одно: и как мы раньше без всего этого обходились?

А главное - Вы начали задавать правильные вопросы, а это уже половина дела. А уж ответы на них найдутся.

я еще поспрошаю, хорошо?

Конечно, обращайтесь. Кстати, как у Вас обстоит дело с английским? Ибо львиная доля материалов на русский не переведена, придется читать в оригинале.

[jur]

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

На самом деле там все просто и логично. :)
Нужно только подобрать правильные книги. Тогда после их прочтения непонятным останется только одно: и как мы раньше без всего этого обходились?

Интуитивно я это чувствовал, но пока сам "не наступишь на грабли" - не узнаешь, каково зто: получить черенком по лбу! А любопытно! :-)

Кстати, как у Вас обстоит дело с английским? Ибо львиная доля материалов на русский не переведена, придется читать в оригинале.

С английским - неоднозначно. Когда на 4-м курсе института я пришел на экзамен по английскому (сел, как всегда, в конце аудитории), наша англичанка меня сразу увидела и спросила: "Юргис, а ты зачем пришел?!" :-) Следует заметить, что аудитория была большая, сдавало сразу несколько групп.

На том экзамене я свою выстраданную тройку получил :-) Но, когда пришел на работу, - все кардинально изменилось. Нужно разрабатывать приборы. Их цифровую часть. А из документации в наличии только каталоги фирмы TI, позднее Intel. Сначала переводил со словарем, потом без оного. Увидела бы меня через пару-тройку лет наша англичанка - упала бы на колени и вознесла бы молитву чуду дивному, невиданному! :-) Что Я могу почти свободно читать текст на английском! :-)

Прошу прощения, я немного отвлекся. Сейчас я читаю книгу "Pragmatic Version Control using Subversion (2nd edition)". Не скажу, что все понимаю, но проблема главным образом в новизне материала, и только потом в языке. Параллельно читаю "Управление версиями в Subversion" на русском. Это несколько проще... :-)

[Dale]

Я могу почти свободно читать текст на английском!

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

Сейчас я читаю книгу "Pragmatic Version Control using Subversion (2nd edition)". Не скажу, что все понимаю, но проблема главным образом в новизне материала, и только потом в языке.

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

И еще учтите, что в этой теме есть проблема курицы и яйца, поскольку несколько дисциплин очень тесно переплетаются.

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

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

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

Это я не для того, чтобы заранее напугать, а лишь чтобы обрисовать общую картину и примерное место управления версиями в общем процессе. Ничего реально сложного здесь нет, в основе лежат весьма простые и разумные идеи.