Czy powinniśmy umieścić dokumenty specyfikacji w systemie kontroli źródła, takim jak svn?

11

Dzisiaj, jeden z moich współpracowników i ja debatujemy na temat „Czy powinniśmy umieścić dokumenty specyfikacji w systemie kontroli źródła, takim jak SVN?”. Moim zdaniem tak powinno być. Wszystko, co dotyczy opracowywania projektu, powinno być dokładnie kontrolowane za pomocą systemu kontroli źródła. Czy to niewłaściwa koncepcja w procesie tworzenia oprogramowania?

version-control specifications

— Edison Chuang
źródło

4

Co jeśli większość systemów kontroli źródła przechowuje je tylko jako obiekty BLOB? Większość ludzi nie zdradza różnic między dokumentami, ale jeśli tak, zawsze możesz uzyskać dwie wersje i użyć funkcji systemu tworzenia treści, aby je rozróżnić.

— SnoopDougieDoug
źródło

2

To prawda, że cieszę się, jeśli SVN upewnia się, że zawsze mam aktualną wersję. Różnice są mniej ważne przez większość czasu.

— Zachary K

To nie jedyny problem, blokowanie i zastępowanie zmian jest problemem, gdy jest wielu redaktorów

— Nicole

1

Różnicowanie dokumentów nie jest dla Ciebie ważne. Ale dla premiera możliwość zobaczenia zmian w specyfikacji jest bardzo ważna.

— Martin York,

Ta odpowiedź wydaje się bardziej komentarzem na temat innej odpowiedzi. Na przykład pytanie nie wspomina nic o obiektach blob.

— Bryan Oakley

15

Mając miejsce na dysku twardym za grosze na gigabajt miesięcznie, nie ma dobrego powodu, aby nie umieszczać dokumentów w systemie kontroli źródła i jest to prawdopodobnie przydatne. Moje osobiste preferencje to pisanie dokumentów przy użyciu wbudowanych znaczników, np. Wiki Markup lub DocBook . Pozwala to na użycie potężnych narzędzi do porównywania i weryfikacji dokumentów.

— Kevin Cline
źródło

3

Jeśli nic innego, zabawnie jest zobaczyć, jak wyglądała wersja 1.0 specyfikacji, w porównaniu do statków!

— Martin Beckett

8

Dokumentacja specyfikacji wersji jest zdecydowanie godnym celem.

Czy jednak Twoja specyfikacja dokumentuje tylko tekst i jako zwykły plik tekstowy ? Jeśli tak, może to być dobre rozwiązanie.

Jeśli nie, kontrola źródła prawdopodobnie nie jest dla nich właściwym miejscem - kontrola źródła jest zła dla plików binarnych .

Zwykle zwykłe pliki tekstowe nie są tak dobre do formatowania, ani do szybkiego przeglądania, więc wiki z wersjonowaniem jest prawdopodobnie lepszym pomysłem.

— Nicole
źródło

Zwykle nasz dokument zawiera nie tylko zwykły tekst, ale także obraz, taki jak diagram UML lub coś podobnego. Całkowicie się zgadzam, że pliki w formacie binarnym nie są odpowiednie dla systemu kontroli źródła. Myślę jednak, że jest to lepsze niż nic. dobrze? Gdyby istniały wiki, możemy je adoptować. Byłoby świetnie. Ale martwię się o to. Nasi ludzie byliby „zbyt zajęci”, aby nauczyć się korzystać z wiki. (Smutne)

— Edison Chuang

1

Obecnie istnieje wiele stron wiki z edytorami WYSIWYG. Jestem bardzo niechętnym konwersją sharepoint. Jako programista nienawidziłem programu SharePoint z pasją. Następnie zarejestrowałem się w Microsoft BPOS, który jest wyposażony w sharepoint i użyłem go do współpracy przy projektach ze zdalnymi członkami zespołu. Ma wiki, fora, kalendarze i biblioteki dokumentów (które śledzą dokumenty Microsoft Office Docs) i wiele innych rzeczy, które sprawiają, że współpraca przy projektach jest bardzo prosta. Myślę, że Wiki jako żywa specyfikacja jest idealna ze względu na historię, którą zapewnia.

— Michael Brown

Ściśle mówiąc, kontrola źródła nie jest zła dla plików binarnych. To nie tak, że niszczy je lub mutuje. Prawdopodobnie jednak pliki binarne źle wpływają na kontrolę źródła, ale tylko dlatego, że zajmują dużo miejsca na dysku i spowalniają klonowanie. Miejsce na dysku jest jednak tanie, więc nie jest tak złe, jak jeszcze 5 lat temu.

— Bryan Oakley

1

Wszystkie dokumenty powinny być w jakiejś formie archiwum (najlepiej z kontrolą zmian).

Systemy kontroli źródła to jedno rozwiązanie. Ale zwykle systemy te są przeznaczone do dokumentów tekstowych. W związku z tym rzeczy takie jak dokumenty Word lub RTF itp. Nie pasują tak dobrze (szczególnie, gdy próbujesz porównać inną wersję).

Ale istnieją inne rozwiązania zaprojektowane specjalnie dla dokumentów. SharePoint przychodzi mi na myśl, ale jestem pewien, że są jeszcze inne.

— Martin York
źródło

0

Zdecydowanie. Problem polegający na tym, że dokumenty są przechowywane jako pliki binarne (na przykład dokumenty słowne), jest denerwujący. Dobrym rozwiązaniem jest użycie jednego z narzędzi Tortoise (próbowałem SVN i Mercurial), możesz wybrać „Visual Diff”, który pozwala wybrać docdiff. Dzięki docdiff zobaczysz wszystkie zmiany kolorów i innych rzeczy :-). Główną wadą jest to, że za każdym razem, gdy dokonujesz zmiany, cały dokument jest ponownie zatwierdzany (nie tylko zmiana). Ale biorąc pod uwagę, że dokumenty tekstowe zwykle nie są duże i że przestrzeń prawdopodobnie nie jest twoim głównym problemem, nie stanowi to problemu.

Jestem pewien, że możesz używać docdiff bez Tortoise, po prostu tego nie próbowałem.

— Omar Kohl
źródło

Nie rozwiązuje jednak problemu „Zastępowanie zmian wielu edytorów”.

— Omar Kohl

0

Istnieje alternatywne podejście, które należy omówić: BDD

Proszę rozważyć rozwój oparty na zachowaniu ze specyfikacjami wykonywalnymi. Twoje specyfikacje zostaną uproszczone do serii zestawów podanych - Kiedy - Następnie, które są przechowywane w plikach tekstowych. Narzędzie BDD, takie jak Cucumber lub SpecFlow, konwertuje te pliki tekstowe na testy wykonywalne, które może wykonać narzędzie do budowania.

Ogórek: http://cukes.info/ - BDD dla Ruby

SpecFlow: http://www.specflow.org/ - BDD dla .Net

Aby zapoznać się z szybką prezentacją przepływu pracy za pomocą narzędzia takiego jak SpecFlow, zapoznaj się z instrukcją dla Roba Conery'ego SpecFlow: http://tekpub.com/view/concepts/5

Teraz nie tylko wersjonujesz swój kod, ale twoje specyfikacje, a twoje narzędzie do ciągłej integracji (zdaniem TeamCity, CruiseControl, Hudson itp.) Wymusza, aby wszystkie specyfikacje były nadal aktualne na KAŻDEJ kompilacji ... Czy to dla ciebie cenne?

— Jeff Fritz
źródło