Чи слід розміщувати специфікаційні документи в системі управління джерелами, такі як svn?


11

Сьогодні у мого колеги і у мене дискусія на тему "Чи варто розміщувати специфікаційні документи в системі контролю джерел, наприклад SVN?". На мою думку, так і повинно бути. Все, що стосується розробки проекту, слід ретельно контролювати з системою управління джерелами. Це неправильна концепція в процесі розробки програмного забезпечення?

Відповіді:


4

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


2
Щоправда, я щасливий, якщо SVN просто переконує, що у мене завжди є поточна версія. Відмінності є менш важливими у більшості випадків.
Захарій К

Це не єдина проблема, блокування та перезапис змін - це проблема, коли є кілька редакторів
Ніколь,

1
Відмінні документи для вас не важливі. Але прем'єр-міністру можливість бачити зміни в специфікаціях дуже важлива.
Мартін Йорк

Ця відповідь більше схожа на коментар до якоїсь іншої відповіді. Наприклад, питання нічого не згадує про краплі.
Брайан Оуклі

15

Оскільки на жорсткому диску розміщено копійок за гігабайт на місяць, немає вагомих причин не ставити документи в систему управління джерелами, і це, ймовірно, стане в нагоді. Мої особисті переваги - писати документи, використовуючи вбудовану розмітку, наприклад, розмітку Wiki або DocBook . Це дозволяє використовувати потужні інструменти для порівняння та перегляду документів.


3
Якщо нічого іншого, то забавно бачити, як виглядав v1.0 специфікацій, порівняно з якими кораблями!
Мартін Бекетт

8

Документація щодо специфікації версій - це, безумовно, гідна мета.

Однак, чи є ваші специфікаційні документи лише текстовими та у простому текстовому файлі ? Якщо це так, це може бути хорошим рішенням.

Якщо ні, то керування джерелами, ймовірно, не є правильним місцем для них - керування джерелом погано впливає на бінарні файли .

Зазвичай прості текстові файли не є настільки хорошими ні для форматування, ні для швидкого перегляду, тому вікі з версіями, мабуть, краща ідея.


Зазвичай наш документ включає не лише звичайний текстовий вміст, а й такі зображення, як UML-діаграма чи щось подібне. Я повністю погоджуюся, що двійкові форматовані файли не підходять для системи управління джерелами. Однак я думаю, що це краще, ніж нічого. правильно? Якщо були вікі, ми могли б прийняти. Було б чудово. Але я хвилююся з цього приводу. Наші люди були б "надто зайняті", щоб навчитися користуватися вікі. (Сумно)
Едісон Чуанг

1
Зараз у редакторах WYSIWYG багато вікі-файлів. Я дуже неохоче став конвертувати. Як розробник, я ненавиджу пристрасть до Sharepoint. Тоді я підписався з Microsoft BPOS, який постачається з Sharepoint і використовував його для співпраці над проектами з віддаленими членами команди. У ньому є бібліотеки вікі, форуми, календарі та бібліотеки документів (що робить відстеження для Microsoft Office Docs) та безліч інших речей, які просто сприяють спільній роботі над проектами. Я думаю, що Вікі як жива специфікація ідеальна завдяки історії, яку вона надає.
Майкл Браун

Строго кажучи, керування джерелами не є поганим для бінарних файлів. Це не так, як їх якимось чином знищує або мутує. Можливо, бінарні файли погано керують джерелами, але лише тому, що вони займають багато дискового простору та роблять клонування повільніше. Дисковий простір дешевий, тому це не так вже й погано, як це було ще 5 років тому.
Брайан Оуклі

1

Усі документи повинні бути в якомусь вигляді архіву (бажано, з контролем редагування).

Системи управління джерелами - це одне рішення. Але зазвичай ці системи розроблені для звичайних текстових документів. Таким чином, такі речі, як Word або RTF документи тощо, не так добре підходять (особливо, коли ви намагаєтеся порівнювати різні версії).

Але є й інші рішення, спеціально розроблені для документів. SharePoint спадає на думку, але я впевнений, що є й інші.


0

Безумовно. Проблема в тому, що документи зберігаються як бінарні файли (наприклад, текстові документи), дратує. Приємним рішенням є те, що якщо ви використовуєте один із інструментів «Черепаха» (я спробував SVN та Mercurial), ви можете вибрати «Visual Diff», який дозволяє вибрати docdiff. За допомогою docdiff ви можете побачити всі зміни кольорів та речей :-). Основним недоліком є ​​те, що кожного разу, коли ви вносите зміни, весь документ знову вводять у дію (а не лише зміни). Але зважаючи на те, що текстові документи зазвичай не величезні, і це місце, ймовірно, не є вашою основною проблемою, це не проблема.

Я впевнений, що ви можете використовувати docdiff без черепахи, я просто не намагався.


Однак він не стосується проблеми "Перезапис змін у кількох редакторах".
Омар Коль

0

Існує альтернативний підхід, який ви повинні обговорити: BDD

Будь ласка, врахуйте розробку, спричинену поведінкою, із виконаними характеристиками. Ваші технічні характеристики спрощуються в ряд заданих - коли - потім наборів операторів, які зберігаються у текстових файлах. Інструмент BDD, такий як Cucumber або SpecFlow, перетворює ці текстові файли у виконувані тести, які може виконувати ваш інструмент збирання.

Огірок: http://cukes.info/ - BDD для Ruby

SpecFlow: http://www.specflow.org/ - BDD для .Net

Для швидкої демонстрації робочого процесу з таким інструментом, як SpecFlow, перевірте проробку SpecFlow Rob Conery: http://tekpub.com/view/concepts/5

Тепер ви не тільки оновлюєте свій код, але і свої технічні характеристики, і ваш інструмент постійної інтеграції (думаю, TeamCity, CruiseControl, Хадсон тощо) домагається того, щоб усі технічні характеристики все ще були дійсні для КОЖНОГО складання ... Це для вас цінне?

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.