1. 오직 소스 온리
2. 간단한 텍스트 파일 정도로 업무 이력 관리도 추가
3. 이미지 및 기타 등등 리소스 까지도 관리
-- 보통 개인 PC에서 개발 서버 돌려서 테스트 한 뒤 배포하는 스타일에서 종종 보이는 부분
4. 그외 잡다한 모든 것을 SVN에서 관리
어떤 것까지 SVN에서 관리 시키고 있냐 ?
ㅇㅇ ?
SVN과 다른 시스템들 연계 시킬수록 좀 더 관리하는게 늘어나는 것 같던데.
ㅇㅇ
1. 오직 소스 온리
2. 간단한 텍스트 파일 정도로 업무 이력 관리도 추가
3. 이미지 및 기타 등등 리소스 까지도 관리
-- 보통 개인 PC에서 개발 서버 돌려서 테스트 한 뒤 배포하는 스타일에서 종종 보이는 부분
4. 그외 잡다한 모든 것을 SVN에서 관리
어떤 것까지 SVN에서 관리 시키고 있냐 ?
ㅇㅇ ?
SVN과 다른 시스템들 연계 시킬수록 좀 더 관리하는게 늘어나는 것 같던데.
ㅇㅇ
논바이너리파일스온리그리고hg노svn
소스 관리의 경우 대체로 non-바이너리 관리에 간단한 작업 이력 정도 추가를 위해서 텍스트 파일 정도로 이력 추가 하는 정도가 일반적이긴 한데.. TRAC/레드마인/맨티스 등 이력 관리툴이랑 묶는 경우도 있어서 좀 더 다양하게 쓰는 것은 봤음. ㅇㅇ
보통 대용량 바이너리는 FTP로 관리하고, 히스토리 관리 대상인 소스만 SVN 관리하는게 일반적이긴 한데..
버젼히토리는커및로그
TRAC이나 맨티스, 레드마인 또는 기타 문제점 리포팅 툴을 이용해서 비개발자가 문제 등록하고, 그 이력을 SVN 및 기타 등등과 묶으면서 단순 SVN history만으로 이력 관리 하지 않는 케이스도 종종 있음. ㅇㅇ
그땐jira
보통 커밋 자체가 자주 발생하기도 하고.. 커밋 자체 기록은 간단하게 끝나는 경우가 많아서 작업 이력 자체를 해당 업무 아이템 별로 별도의 텍스트로 만들어서 추가 관리하는 경우도 있음. 단순하게 소스 수정 이력 외의 정보도 담기 위해서 ㅇㅇ
개인커밋은내리포에온리프루브드코드만메인리포로푸시
ㅇㅇ