기존 오픈 소스 프로젝트의 소스 제어/관리

Question

현재 테스트 서버에 오픈 소스 프로젝트를 설치 및 구성 중입니다. 필자는 소스 컨트롤을 사용하도록 잘 훈련 받았고, 내가하는 모든 일이 올바르게 관리되도록하고 싶습니다. (나, 유일한 개발자/관리자, 그리고 미래의 메인터너 모두에게). 오픈 소스 프로젝트는 소스 다운로드 또는 svn 체크 아웃으로 사용할 수 있습니다.

프로젝트의 소스 제어 버전을 갖고 싶습니다. 나는 (자바 서블릿) 코드를 많이 변경하고 싶지는 않지만 구성, XML 파일, XSL, CSS 등이 모두 포함되어있어 소스 제어를 원한다.

모든 소스 코드를 로컬 저장소에 저장해야합니까? 변경해야하는 파일 만 제어해야합니까? 이 경우 디렉토리 구조가 일치해야하므로 빌드 디렉토리에 직접 체크 아웃 할 수 있습니다.

Answer 1

동일한 디렉토리 트리에 대해 두 번의 체크 아웃이 작동하지 않습니다 . 소스를 체크 아웃하고 OSS 프로젝트 소스를 체크 아웃하려고한다면, 그들이 공통으로 가지고있는 디렉토리는 이미 다른 프로젝트의 작업 디렉토리라고 말하면서 실패 할 것이다.

css, xml, xsl 등을 공통 디렉토리에 모을 수 있다면 자신의 프로젝트의 svn에있는 단일 디렉토리에 넣고 OSS의 작업 디렉토리에있는 디렉토리로 체크 아웃 할 수 있습니다 계획.

~/작업 => SVN : // samhoice/프로젝트/트렁크

~/작업/osscomponent => SVN : // osshost/프로젝트/latesttag

~/작업/osscomponent/config => svn : // samhoice/project/trunk/config

이 구조에서 osscomponent 디렉토리는 samhoice의 svn 저장소에 없습니다. 이 파일은 설치 스크립트에 의해 OSS 프로젝트의 작업 디렉토리 루트로 추가됩니다.config 디렉토리는 OSS 프로젝트에서 체크 아웃되지 않았으며 거기에 존재하지 않습니다. config 디렉토리는 설정 스크립트에 의해 생성되고 config 디렉토리는 프로젝트 저장소에서 체크 아웃됩니다.

그래서이 디렉토리 구조에는 세 가지 체크 아웃이 있습니다. 재귀 적 중첩이 없으므로 모든 하위 디렉토리의 svn 매핑간에 충돌이 없습니다.

OSS 프로젝트 구조 내에 구성 파일을 배치해야하는 경우 makefile 또는 구성 스크립트에 일부 심볼릭 링크를 추가하십시오. 당신은 아마 당신의 svn 클라이언트에서 포스트 체크 아웃 후크에서 이것을 할 수 있습니다.

두 프로젝트 트리 사이에 코드를 공유하기 위해 내 프로젝트 중 하나에 이와 같은 구조를 사용합니다. 공유 항목은 내가 설정 섹션에 권장하는 하위 트리에 있습니다.

Answer 2

코드를 변경하고 싶지 않거나 지금 이유를 알지 못하더라도 나중에 다른 사람이 이유를 볼 수 있기 때문에 모든 코드를 체크인합니다.

branches/ 
tags/ 
trunk/ 

그리고 (그 세 아래) 일반 디렉토리 레이아웃한다 : 또한, 버그, 또는 등 유지 보수 나 성능을 개선하기 위해 간단한 리팩토링 .. SVN에 대한 기본 레이아웃이 될 것

가있을 수 있습니다 물론 응용 프로그램과 일치 시켜서 체크 아웃하고 바로 실행할 수 있습니다. 당신은 그러나 빌드 파일 등을 통해 약간의 수정을 할 수 있습니다.하지만 체크 아웃을 가서 항상 좋은 것 같아요. 자세한 정보 나 모범 사례에 대한 포인터를 보려면 기술을 사용하는 다른 오픈 소스 프로젝트를 살펴보아야합니다.

구성 파일 - 해당 파일을 확인하지 않습니다. 그러나 대부분의 프로젝트는 사용자에게 모든 구성 옵션을 보여주는 foo-dist 파일을 체크인합니다. 최소한 기본 설정을 사용하려면 foo-dist을 foo으로 복사해야합니다. 또한

, 당신은 버전 제어를 포함하여 프로젝트 호스팅 Google Code, Sourceforge 또는 github 봤어? 3 개 모두 무료로 1 톤을 제공하며 프로젝트 호스팅 등을 위해 서버를 돌볼 필요가 없다는 점에서 무료입니다.

Answer 3

나는 몇몇의 크기에 따라 방법, 및, 제 3 자 프로젝트에 사용자 정의의 양을 사용했습니다 : 나는를 확인합니다 작거나 고도의 맞춤형 프로젝트를 들어

• 을 주식 코드로 시작하는 모든 일들. 이를 통해 전체 프로젝트에서 쉽게 작업 할 수 있으며 "원 스톱 쇼핑"을 통해 구축에 필요한 모든 것을 확인할 수 있습니다.

• 가 크거나 약간 맞춤형 프로젝트을 위해 나는 주식 아카이브 (일반적으로 .tar.bz2 또는 .zip 파일)의 사본을 유지하고 백업되고 있는지 알 수있을 것입니다. 그런 다음 사용자 정의를 구현하는 파일을 수정 관리하에 유지할 것입니다. 여기에 옵션이 있습니다.

  • 맞춤 파일 자체를 체크인하십시오. 소스 코드를 수정하는 경우 일반적으로이 옵션을 사용하는 것이 가장 좋습니다.

  • 사용자 정의를 수행하는 스크립트를 체크인하십시오. 이는 스크립트가 구성 유틸리티에 입력을 제공 할 때 가장 효과적입니다. 사용자 지정 내용 (입력 데이터)을 저장 부분 (구성 유틸리티)과 별도로 저장하기 때문입니다. 타사 라이브러리의 새 버전이 출시되면 대개 사용자 지정을 적용하여 중요한 업그레이드가 가능합니다. "™를 변경하지 않습니다"또는있는 고객이 어딘가에, 은 계약시 특정 버전을 결합 상점 주식 코드를 가지고 있고, 개정 통제하에 패치 파일을 만드는 것이 프로젝트의

• . 그런 다음 "승인 된"버전의 패치를 릴리스 할 수 있습니다. 참고 : 패치 파일은 유지 관리에 지장이 있기 때문에 이것은 매우 끔찍한 선택입니다. 새 패치를 만들 경우 패치 파일을 다시 만들거나 첫 번째 패치 위에 적용되는 추가 패치를 만들어야합니다. 이 옵션을 선택하는 이유는 기술적 인 이유 때문에 일반적으로 선택되지 않습니다.

나는 _you는 이런 종류의 프로젝트를 구축하고 사용자 정의를 추가하는 전체 프로세스를 문서화 할 필요가 충분히 있다고 강조하거나 자동화, 또는 (바람직하게는) 모두 없습니다. 어떤 파일이 어디에 있는지 또는 누구에게 속한 지 잊어 버리기가 놀랍도록 쉽습니다. 처음부터 다시 시작하는 것은 고통 스럽습니다. 특히 당신이 후계자라면.

행운을 빈다.