Сегодня один из моих коллег и я обсуждаем вопрос: «Должны ли мы поместить спецификации документов в систему контроля версий, такую как SVN?». На мой взгляд, так и должно быть. Все, что связано с разработкой проекта, должно тщательно контролироваться системой контроля версий. Это неправильная концепция в процессе разработки программного обеспечения?
Ответы:
Так что, если большинство систем контроля версий хранят их только в виде больших двоичных объектов? Большинство людей не разобрались в различиях между документами, но если вы это сделаете, вы всегда можете получить две версии и использовать функцию авторской системы для их сравнения.
Если на жестком диске копейки в гигабайтах в месяц, нет веской причины не помещать документы в систему контроля версий, и это, вероятно, будет полезно. Лично я предпочитаю писать документы с использованием встроенной разметки, например, Wiki Markup или DocBook . Это позволяет использовать мощные инструменты для сравнения и ревизии документов.
Создание версий спецификации документов, безусловно, является достойной целью.
Тем не менее, ваши документы спецификации только для текста и в текстовом файле ? Если это так, это может быть хорошим решением.
Если нет, то контроль источника, вероятно, не для них - управление исходным кодом плохо для двоичных файлов .
Обычно простые текстовые файлы не так хороши для форматирования или быстрого просмотра, поэтому вики с версионированием, вероятно, является лучшей идеей.
Все документы должны быть в какой-то форме в архиве (желательно с контролем версий).
Системы контроля версий - одно из решений. Но обычно эти системы предназначены для простых текстовых документов. Таким образом, такие вещи, как документы Word или RTF и т. Д., Не очень хорошо подходят (особенно когда вы пытаетесь сравнить другую версию).
Но есть и другие решения, специально предназначенные для документов. SharePoint приходит на ум, но я уверен, что есть и другие.
Определенно. Проблема, что документы хранятся как двоичные файлы (например, текстовые документы), раздражает. Хороший обходной путь - если вы используете один из инструментов Tortoise (я пробовал SVN и Mercurial), вы можете выбрать «Visual Diff», который позволяет вам выбрать docdiff. С docdiff вы можете видеть все изменения с цветами и прочим :-). Основным недостатком является то, что каждый раз, когда вы вносите изменения, весь документ фиксируется снова (а не только изменение). Но, учитывая, что текстовые документы обычно не очень большие, и это пространство, вероятно, не ваша основная проблема, это не проблема.
Я уверен, что вы можете использовать docdiff без черепахи, просто я не пробовал.
Есть альтернативный подход, который вы должны обсудить: BDD
Обратите внимание на Behavior Driven Development с исполняемыми спецификациями Ваши спецификации упрощаются в серии наборов «даны - когда - тогда», которые хранятся в текстовых файлах. Инструмент BDD, такой как Cucumber или SpecFlow, преобразует эти текстовые файлы в исполняемые тесты, которые может выполнять ваш инструмент сборки.
Огурец: http://cukes.info/ - BDD для Ruby
SpecFlow: http://www.specflow.org/ - BDD для .Net
Для быстрой демонстрации рабочего процесса с помощью такого инструмента, как SpecFlow, ознакомьтесь с кратким обзором Роба Конери по SpecFlow: http://tekpub.com/view/concepts/5
Теперь не только вы создаете версии своего кода, но и свои спецификации, и ваш инструмент непрерывной интеграции (например, TeamCity, CruiseControl, Hudson и т. Д.) Обеспечивает выполнение всех спецификаций в КАЖДОЙ сборке ... Это ценно для вас?