MUGRAMMER

특정 디렉토리/파일 권한 설정 목적 : 계정별로 특정 디렉토리나 파일에 대한 읽기/쓰기 권한을 설정하여 승인된 사용자들만 수정할 수 있도록 하여 의도치 않은 변경을 방지한다. 설정순서 : svnserve.conf 수정 passwd 수정 authz 수정 TEST 환경 Repository Root : C:\SVNRepository Repository : TEST_Repository 1. svnserve.conf 수정 위치 : Repository Root\Repository\svnserve.conf ex) C:\SVNRepository\TEST_Repository\svnserve.conf 아래 항목에 대한 주석을 해제하고 환경에 맞게 지정한다. # 인증되지 않은 사용자는 read만 anon-access = r..

C:\Documents and Settings\Administrator>svnadmin help create create: 사용법: svnadmin create REPOS_PATH REPOS_PATH 에 새로운 빈 저장소를 생성합니다. 옵션: --bdb-txn-nosync : 트랜잭션을 커밋에서 fsync를 비활성화합니다[Berkeley DB] --bdb-log-keep : 자동 로그 파일 삭제를 비활성화 합니다 [Berkeley DB] --config-dir ARG : arg로 지정된 디렉토리에서 사용자 구성화일을 읽습니다 --fs-type ARG : 저장소 타입: 'fsfs' (기본값) 또는 'bdb' --pre-1.4-compatible : Subversion 1.4 버전 이전과 호환되는 포맷 이용..

SVN을 사용할 때 가장 신경쓰이는 부분이 누구나 수정할 수 있다는 점이다. 개발자가 많은 경우 공동작업을 진행할 시 문제가 될 수 있어 이 부분이 가장 신경쓰인다. '내가 먼저 수정했네 너가 먼저 수정했네.. 너때문에 소스 꼬였잖아.. 너때문에 내가 개발한 소스 다 날아가버렸잖아~ ' 이런 상황을 미연에 방지 하기 위해 LOCK 기능을 충분히 활용해야 할 필요가 있다. 구현 시나리오. 1) update 받을 때 자동으로 모든 파일을 read-only로 변경. 2) 소스를 checkout(?) 할 때 해당 파일에 lock 존재 유무 파악 lock을 누군가가 잡고 있으면 소스 수정 불가 3) 없으면 getLock 4) commit 후 lock 해제.. 그리고 read-only 뭐 대충 이 정도.. [참고사..

근 3년동안 ClearCase만 사용해 오다가 SVN을 사용하려니 여간 불편한게 아니다. 가장 큰 불편함은 용어가 헷갈린다. ClearCase에선 checkout이 lock을 걸어 해당 소스를 점유할 수 있어 다른 개발자가 해당 소스의 수정을 막는가 하면, 우선 순위를 두어 후에 merge를 하더라도 우선 순위에 따라 이뤄지게 되어있다. 다수의 개발자들이 공동개발을 할 때 그나마 '내 소스를 누가 고치진 않겠지?'라는 고민따윈 하지 않았었는데 SVN은 늘 불안감이 엄습해 온다. 단지 이틀만 사용했을뿐이거늘..;;; 앞으로 불편 사항이 계속 생겨날 것 같은 불길한 예감이 든다. '제 소스가 사라졌어요~' ,'이거 사용법을 잘 모르겠어요~ '라며 얼마나 귀찮게 할런지.. 눈에 선하다.. 역시 돈내고 사용하는..