답변:
그렇다면 대부분의 소스 제어 시스템이이를 블롭으로 만 저장한다면 어떨까요? 대부분의 사람들은 문서 간의 차이점에 대해 언급하지 않지만, 그렇게하면 항상 두 가지 버전을 얻을 수 있으며 제작 시스템의 기능을 사용하여 차이점을 파악할 수 있습니다.
한 달에 기가 바이트 당 페니에 하드 디스크 공간이 있으면 소스 제어 시스템에 문서를 넣지 않을 이유가 없으며 유용 할 것입니다. 개인적으로 선호하는 것은 Wiki Markup 또는 DocBook 과 같은 인라인 마크 업을 사용하여 문서를 작성하는 것 입니다. 이를 통해 문서 비교 및 개정을위한 강력한 도구를 사용할 수 있습니다.
버전 사양 문서는 확실히 가치있는 목표입니다.
그러나 사양 문서는 텍스트 전용 이며 일반 텍스트 파일로되어 있습니까? 그렇다면 이것이 좋은 해결책 일 수 있습니다.
그렇지 않다면 소스 제어는 아마도 적절한 위치가 아닐 것입니다. 소스 제어는 이진 파일에 좋지 않습니다 .
일반적으로 일반 텍스트 파일은 형식 화나 빠른보기에 적합하지 않으므로 버전 관리 기능이 있는 Wiki 가 더 좋습니다.
명확히. 문서가 이진 파일 (예 : 단어 문서)로 저장되는 문제는 성가신 일입니다. 좋은 해결책은 Tortoise 도구 (SVN 및 Mercurial을 사용해 보았습니다) 중 하나를 사용하는 경우 docdiff를 선택할 수있는 "Visual Diff"를 선택할 수 있다는 것입니다. docdiff를 사용하면 색상과 물건으로 모든 변경 사항을 볼 수 있습니다 :-). 가장 큰 단점은 변경할 때마다 전체 문서가 다시 커밋된다는 것입니다 (변경뿐 아니라). 그러나 텍스트 문서가 일반적으로 크지 않으며 공간이 아마도 주요 문제가 아니라는 것을 고려할 때 이것은 문제가되지 않습니다.
Tortoise없이 docdiff를 사용할 수 있다고 확신합니다. 단지 시도하지 않았습니다.
논의해야 할 대안이 있습니다 : BDD
실행 가능한 사양의 행동 주도 개발을 고려하십시오. 스펙은 텍스트 파일에 저장된 일련의 Given-When-When 문 세트로 단순화됩니다. Cucumber 또는 SpecFlow와 같은 BDD 도구는 해당 텍스트 파일을 실행 가능한 테스트로 변환하여 빌드 도구가 실행할 수 있도록합니다.
오이 : http://cukes.info/-Ruby 용 BDD
SpecFlow : http://www.specflow.org/-.Net 용 BDD
SpecFlow와 같은 도구를 사용하여 워크 플로를 빠르게 시연하려면 Rob Conery의 SpecFlow 연습을 확인하십시오. http://tekpub.com/view/concepts/5
이제 코드 버전을 지정할뿐만 아니라 사양 및 Continuous Integration 도구 (TeamCity, CruiseControl, Hudson 등)가 모든 사양이 모든 빌드에서 여전히 유효하도록 강제하고 있습니다. 귀중한가?