Должны ли мы помещать документы спецификации в систему контроля версий, такую ​​как svn?

11

Сегодня один из моих коллег и я обсуждаем вопрос: «Должны ли мы поместить спецификации документов в систему контроля версий, такую ​​как SVN?». На мой взгляд, так и должно быть. Все, что связано с разработкой проекта, должно тщательно контролироваться системой контроля версий. Это неправильная концепция в процессе разработки программного обеспечения?

version-control specifications Эдисон Чуанг
источник

Ответы:

4

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

SnoopDougieDoug
источник
2
Правда, я рад, если SVN просто гарантирует, что у меня всегда есть текущая версия. Различия в большинстве случаев менее важны.
Захари К
Это не единственная проблема, блокировка и перезапись изменений - это проблема, когда есть несколько редакторов
Николь
1
Различение документов для вас не важно. Но для менеджера очень важно видеть изменения в спецификациях.
Мартин Йорк,
Этот ответ больше похож на комментарий о каком-то другом ответе. Например, в вопросе ничего не говорится о каплях.
Брайан Окли
15

Если на жестком диске копейки в гигабайтах в месяц, нет веской причины не помещать документы в систему контроля версий, и это, вероятно, будет полезно. Лично я предпочитаю писать документы с использованием встроенной разметки, например, Wiki Markup или DocBook . Это позволяет использовать мощные инструменты для сравнения и ревизии документов.

Кевин Клайн
источник
3
Если ничего другого, это забавно видеть, как v1.0 из спецификаций выглядел по сравнению с тем, какие корабли!
Мартин Беккет
8

Создание версий спецификации документов, безусловно, является достойной целью.

Тем не менее, ваши документы спецификации только для текста и в текстовом файле ? Если это так, это может быть хорошим решением.

Если нет, то контроль источника, вероятно, не для них - управление исходным кодом плохо для двоичных файлов .

Обычно простые текстовые файлы не так хороши для форматирования или быстрого просмотра, поэтому вики с версионированием, вероятно, является лучшей идеей.

Николь
источник
Обычно наш документ включает в себя не только текстовое содержимое, но и изображение, такое как UML-диаграмма или что-то в этом роде. Я полностью согласен с тем, что двоичные файлы не подходят для системы контроля версий. Тем не менее, я думаю, что это лучше, чем ничего. верно? Если бы были вики, мы могли бы принять. Это было бы прекрасно. Но я беспокоюсь об этом. Наши люди были бы «слишком заняты», чтобы научиться пользоваться вики. (Печально)
Эдисон Чуанг,
1
В настоящее время существует много вики с редакторами WYSIWYG. Я очень неохотно обращаюсь с sharepoint. Как разработчик, я ненавидел sharepoint со страстью. Затем я зарегистрировался в Microsoft BPOS, который поставляется с sharepoint, и использовал его для совместной работы над проектами с удаленными членами команды. Он имеет вики, форумы, календари и библиотеки документов (которые отслеживают документы Microsoft Office) и множество других вещей, которые просто упрощают совместную работу над проектом. Я думаю, что Wiki как живая спецификация идеальна из-за истории, которую она предоставляет.
Майкл Браун
Строго говоря, контроль исходного кода неплох для двоичных файлов. Это не так, как будто это разрушает или мутирует их каким-то образом. Возможно, однако, что двоичные файлы плохо подходят для управления исходным кодом, но только потому, что они занимают много места на диске и замедляют клонирование. Дисковое пространство, тем не менее, дешево, поэтому не так плохо, как 5 лет назад.
Брайан Оукли
1

Все документы должны быть в какой-то форме в архиве (желательно с контролем версий).

Системы контроля версий - одно из решений. Но обычно эти системы предназначены для простых текстовых документов. Таким образом, такие вещи, как документы Word или RTF и т. Д., Не очень хорошо подходят (особенно когда вы пытаетесь сравнить другую версию).

Но есть и другие решения, специально предназначенные для документов. SharePoint приходит на ум, но я уверен, что есть и другие.

Мартин Йорк
источник
0

Определенно. Проблема, что документы хранятся как двоичные файлы (например, текстовые документы), раздражает. Хороший обходной путь - если вы используете один из инструментов Tortoise (я пробовал SVN и Mercurial), вы можете выбрать «Visual Diff», который позволяет вам выбрать docdiff. С docdiff вы можете видеть все изменения с цветами и прочим :-). Основным недостатком является то, что каждый раз, когда вы вносите изменения, весь документ фиксируется снова (а не только изменение). Но, учитывая, что текстовые документы обычно не очень большие, и это пространство, вероятно, не ваша основная проблема, это не проблема.

Я уверен, что вы можете использовать docdiff без черепахи, просто я не пробовал.

Омар Коля
источник
Это не решает проблему «перезаписи изменений из нескольких редакторов».
Омар Кол
0

Есть альтернативный подход, который вы должны обсудить: 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 и т. Д.) Обеспечивает выполнение всех спецификаций в КАЖДОЙ сборке ... Это ценно для вас?

Джефф Фриц
источник