'어장 Develop'에 해당되는 글 90건

웹 개발을 하면서 툴팁은 생각보다 많이 쓰인다. 항목별 도움말과 같이 동작할때가 가장 큰데, 이걸 관리자가 직접 관리할 수 있었으면 좋겠다는 요구사항이 나왔다. 허미 대체 이게 뭔말이래. 그러니까 간단하게 요약하자면 다음과 같다.

요구사항

1. 관리자가 툴팁관리 메뉴를 통해, 항목별로 툴팁을 등록/수정 등 관리를 할 수 있을 것

2. 등록된 툴팁은 화면상에서 보여질 것

대충 뭐 이런건데, 우리가 예시를 들자면 '저장'버튼 에 마우스 오버를 하면 '저장을 하기 위한 버튼이에용' 이라고 툴팁이 뜰 것이다.

그런데 저 툴팁메세지를 관리화면을 통해 추후에 바꾸겠다는거다. 이게 유동적으로 돼? 처음에는 반신반의 했는데, 이게 되네?

구현 - ModelAndView

결론적으로는 매우 쉽게 유동적으로 관리가 된다.

간단히 설명하자면, 해당 화면을 로딩하기 위한 controller 에서 ModelAndView에 jsp 경로를 리턴해줄것인데, 이 ModelAndView에 툴팁 Object를 함께 넣어주는 것.

그리고 해당 jsp 에서 툴팁Object 에서 html렌더링시 해당 value를 뽑아다 쓸 수 있는 것이다. 다음의 소스코드를 보자.

소스코드에 작성된 주석과 같이 Map 형태로 툴팁 메시지를 담고, 저걸 modelandview에 넣어준다.

현재 디비가 준비되어있지 않아Map형태로 구현하긴 했지만, 실제로 db 쿼리 시에도 vo 형태로 가져올것이기에 크게 문제가 될 부분은 없다.

그리고 jsp에서는 다음과 같이 꺼내쓰면 끝이다. 완전 쉬움.

그럼 툴팁이 별도 처리 없이 바로 저렇게 보인다. 이렇게 간단하다고?

응용 - 그리드

javascript 형태로 되어진 그리드는 거의 대부분 적용될 것으로 보인다.

ModelAndView로 tooltipMap오브젝트를 담아 jsp로 던졌으니, jsp는 해당 페이지에 매핑된 js로 값을 넘겨주면 된다.

그리고 js에서는 그리드 컬럼을 구성할 때 tooltipMap에서 꺼내 매핑하면 된다.

다음의 소스코드를 보자.

3번째와 같이 JSP에서 JS로 오브젝트 주입을 시도한다.

그리고 js의 그리드 컬럼 설정부에서 tooltip을 저러한 형태로 작성해주면 된다.

이렇게하면 상단의 검색조건/항목의 툴팁과 그리드의 툴팁을 모두 JAVA 에서 가져올 수 있게 된다. 한 건 해결! 

신규 플젝에 투입되면서 공통 웹 개발파트를 맡게 되었다. 그놈의 웹개발은 그만하고 싶긴 한데, 하라면 해야지 뭐. 아무튼, 공통부라길래 그냥 공통 컴포넌트 정도 만지작거릴 줄 알았는데 그게 아니었고, 이번에 많이 배우는 듯 싶다.

서론 . tiles 추가하기에 앞서

현재 전자정부 프레임워크 4.2 버전을 사용중이다.

SI를 하건 뭘 하건 대부분의 웹 페이지는 다음과 같은 레이아웃 구조를 가지고 있다. 

저기서 상단의 Header , 좌측의 Nav, 하단의 Footer는 고정형 이미지이며 Body는 개발자들이 만들어내는 업무페이지라고 보면 된다. 처음에는 Header / Nav / Footer에 해당하는 JSP를 각각 만들고 Include하는 방식으로 생각했었는데 이거 아무리봐도 나이스하지가 않단말이다. 무슨 말이냐 하면, 

이렇게 모든 공통 레이아웃들을 저렇게 주저리주저리 include해야 한다. 우리는 상단의 이미지와 같이 심플한 구조가 아니라 공통 헤더, 공통 타이틀, 공통 네비게이터, 공통 슬라이드 네비게이터, 공통 인피니트탭, 공통 푸터 까지 있으니 위와 같은 방식으로 include file하려면 여섯개는 더 있어야 한다.

가장 큰 문제는 무어냐, 저 포맷을 고대로 갖다 써서 수많은 div태그를 뚫고 업무 화면을 그려내면 좋으련만, 저건 아주 극도로 축약한 div 태그들일 뿐이고 실제로는 약 100여줄에 가까운 태그들이 난무를 하고 있다는거다.

그럼 당연히 개발자의 실수 하나로 레이아웃이 모조리 깨지기도 하고 가독성도 너무 구려서 개발 난이도가 올라간다. 이럴때 무엇을 쓴다? apache tiles다.

tiles를 적용함으로 인해 공통으로 사용하는 레이아웃은 그대로 공통부에서 처리하고 업무 화면을 지정한 div태그의 어딘가에 끼워넣는 개념이라고 보면 된다. 즉, tiles로 사전에 레이아웃을 설정하고 특정 영역만 호출하는 개념이다. 이마리야.

1. tiles 적용 - pom.xml

tiles를 적용하기에 앞서 기본적인 레이아웃에 대한 작업은 퍼블리셔분께서 작업해주셨다고 가정한다. 이것까지 하다간 난 죽을지도 모른다. 아무튼, pom.xml에 다음과 같이 추가했다. GPT는 몇개 안넣어줬는데 돌려보니 계속 오류가 나서, 보태보태 병에 걸려 저렇게까지 추가하고 성공함.

라이브러리들 이름이 참 쉬우니 대충 알아들을건데 뭐 tiles라이브러리 코어모듈, jsp 모듈, 서블릿 제어모듈, api 호출모듈, el 명령어 모듈 정도로 네이밍이 된 듯 싶다. 확실한것인지는 잘 몰루. 아무튼. 여기까지 하고 maven update~ 한다.

2. tiles.xml 설정

pom.xml에 라이브러리를 추가했다면 다음은 tiles.xml을 설정해준다. 공통 레이아웃을 무엇을 쓸지 선언하는 부분이라 보면 된다.

간단히 설명하자면 공통 레이아웃을 commLayout.jsp로, tilesbase라는 이름으로 정의하고

commHeader.jsp를 header , commLeft.jsp는 left , commFooter.jsp는 footer로 태그로 정의하고

하단에는 3depth url 규격에 맞춰서 호출한다는 의미이다. 

현재 우리 시스템은 3depth url규격으로 되어있다. localhost:8080/test/test/test.jsp 라는 형태.

그래서 site/*/*/* 로만 정의해도 문제 없으나, 일단은 혹시몰라 3depth를 모두 개별로 정의했다.

tilesbase, tiles.xml 및 site/* 등등 모든것들은 개발에 맞춰 설정하면 된다.

3. commLayout.jsp생성

예시로 맨 위의 이미지와 같이 첨부하는 방법을 들어줄 것이다. 기본 공통 레이아웃은 div태그별로 잘게 잘 쪼개서 commHeader.jsp, commLeft.jsp, commFooter.jsp와 같은 형태로 만들어준다. 

저 comm시리즈와 함께 우리가 업무에서 만들 것들을 조립하는 큰 판을 commLayout.jsp라고 칭한다. 이 commLayout.jsp에서 블록을 조립하듯 퍼블리셔분께서 작업해주신 div태그 class별로 조립을 하는거다.

노파심에 덧붙여(미래의 이 작업을 할 내게) jsp의 div class 별로 큰 구획들이 잡혀있으니 이것들을 잘게 쪼개면 된다.

큰 class 별로 쪼개서 commHeader, commLeft, commFooter 등등을 만들어 jsp로 만들어두고, commLayout 에서 tiles 에서 설정한 각각의 jsp들을 조립하는 형태다. 다음의 소스코드를 보자.

commLayout.jsp 에서 tiles태그를 사용하여 tiles.xml에서 정의한 jsp들을 include하는 형태이다.

예제 소스코드라서 간략하게 되어있지만, 실제로는 div class의 구조가 복잡하느라 퍼블리셔 작업물을 몇 번이나 확인했는지 모르겠다.

일단 여기까지 설정을 온전하게 잘 했다면 큰 고비는 넘긴것이다.

4. dispatcher-servlet.xml 설정

dispatcher-servlet에서는 spring mvc 구조에서 모든 클라이언트의 요청을 받아 처리하는 부분으로, 일반적으로 jsp view resolver로 설정이 되어있다.

그런데 이렇게 설정했다가는 호출하는 jsp가 먼저 먹어버리니까, 우선순위를 tiles 로 먹도록 설정해야한다. 다음의 설정을 보자. 

dispatcher-servlet에 tiles관련 설정을 넣어준다. 동시에, 모든 view호출은 tiles 우선으로 처리하도록 (그래야 레이아웃이 먹으니) p:order를 0으로 주고, 기존의 view Resolver설정을 유지함과 동시에 후순위(나는 3순위로)로 설정한다.

이게 끝이 아니다. 우리는 Controller 에서 url을 호출하는 부분도 수정해야 한다.

5. 공통 컨트롤러 수정 

나는 위에서 site/*/*/* 형태로 설정했다. 이 말은, ModelAndView 에서 return 하는 uri에 대해 tiles definition이 가로채서 WEB-INF/jsp/{1}/{2}/{3}.jsp 에 있는 jsp를 리턴해준다는 의미이다.

기존에 설정된 viewResolver도 동일하다. 하지만 내가 설정한 것은 site/를 반환하도록 되어있으니, 공통부 ModelAndView에서도 site/ 형태로 반환해야 한다.

그냥 별거 없이, ModelAndView return시 "site/"를 StringBuilder 에서 append해주면 된다. 이건 개발자 구현 나름이니까.

그래서 최종 형태는 다음과 같아야 한다.

이렇게 해줘야 site/ 형태로 url을 리턴하고, tilesResolver가 캐치해서 tiles.xml의 구조로 리턴하게 될 것이다.

그런데 왜 site/형태를 쓸까?

site/ 형태의 url을 쓰지 않으면 모든 경로는 /one/two/three형태로 리턴이 될 것이고, 모든 페이지에 대해 tiles 가 적용이 될 것이다. 이 말인 즉, /login , /error와 같은 수많은 퍼블릭 페이지들도 tiles영향을 받게 된다는 점이다.

그래서 퍼블릭 페이지와의 구분을 위해 내부 페이지들의 구분자 역할을 하는 개념이라 보면 된다.

일단 여기까지, 이 설정을 내부망에서 한다고 얼마나 삽질했던지. 아휴 힘들었다. 

회사에서 자체적으로 제작한 Spring 기반의 프레임워크/튜닝 Eclipse로 개발을 할 일이 생겼는데, 쿼리 작성하는 xml이 뭔가 좀... 다르다? 

대충 내가 지금까지 써온 xml 형태랑 다르다. 

쓰다보니 가장 큰 문제가 바로 Ctrl-z / Ctrl-y를 이용한 되돌리기 기능이 안먹힌다는 것인데, 이러다보니 뭐 하나 잘못 지워버리면 되돌리기가 안되서 -_-;; 아주 난감했다. 어떻게 이 상태로 한 달을 개발했는지 모르겠는데.

아무튼 구글링을 대충 Eclipse xml 되돌리기 로 검색해보니 원인을 찾을 수 있었다.

원인은 '기본 xml 열기 속성이 XML (Spring XML Config File)로 설정' 되어 있었던 것. 이것을 XML Editor로 변경해주니 아주 잘 동작한다.

그래 이렇게 등록되어야 tag 자동완성도 되고 좋지. ㅋㅋㅋ

설정 방법은 다음과 같다. 

Windows -> Preferences -> General -> Editors -> File Associations -> *.xml -> XML Editor 선택 후, Default 클릭.

이렇게 설정하면 XML 에디터로 열려 태그 자동완성부터 시작해서 안먹히던 되돌리기/복구하기도 잘 되고. 코드하이라이터(?)도 잘 보이고 아무튼 좋다. ㅋㅋㅋ 아 진짜 별놈의 설정이 다 있었네. ㅋㅋㅋㅋ 

갑자기 몇년만에 웹 개발을 지원요청받아서 투입되었다. 거기에 생전 처음보는 울 회사 자체 프레임워크로 커스터마이징된 SpringBoot 기반 프레임워크;; 아 이건 또 뭐야. 대체.

아무튼 개발 잘 하고 있는데 엑셀 파싱하고 sysout 으로 출력하는데 한글 인코딩이 깨져서 보인다. 다른 한글들은 잘 출력되는걸 봐서 뭔가 문제가 있는것 같은데, 일단 급한대로 한글이 잘 나오는데만 초점을 두고 GPT 에게 물어보았다.

이렇게 보이는 상황 -_-;

디버깅 모드로 찍어보니 오브젝트 내의 데이터들은 모두 한글로 잘 가져온 상황. 그러니까 파싱문제는 아니다, 이마리야.

일단은 Run Configuration의 VM Argument를 -Dfile.encoding=UTF-8 로 준다거나 하는 설정은 싹 다 줘봤고, windows - preference 의 text encoding 같은것도 UTF-8로 줬는데 문제가 해결되지는 않았다.

다른방법을 더 강구하니 이거 함 써보라고 던져준다.

일단 이렇게 하니까 잘 나온다. 원인 분석까지는 시간이 조금 걸릴듯. 이런건 또 생전 첨보네 ㅡㅡ;; 

CentOS 7 설치 후 yum update -y 하는데 오류가 발생했다.

아 이게 뭔가 하고 찾아보니 CentOS7 지원중단에 따른 미러사이트 오류로 확인되었고, 아래와 같은 수정을 통해 yum update를 수행했다. #ori 항목은 기존의 설정으로 주석처리하고, #new 항목을 신규로 작성하면 된다.

그 후에 정상 업데이트가 됨을 확인할 수 있다.

OS 변경설치를 위해 개인적으로 테스트하기 위해 작성한다.

1. 테스트 데이터 베이스 생성 및 테스트 계정 생성

먼저 테스트용 서버에 PostgreSQL 13을 설치, 신규 데이터베이스 생성과 신규 계정을 생성한다.

만약 순서가 잘못된다면 권한과 관련해서 조금 많이 꼬여버리니까 주의해야한다. 모든 내용은 psql 명령어로 수행했다. 

2. 신규 테이블 생성 및 데이터 입력

여기서부터는 일반 SQL 쿼리와 크게 다르지 않다. 사실 위의 grant 명령어들도 SQL 이나 다를바 없긴 하지만 뭐...

처음에 postgres로 테이블 생성하고 이후에 DBEaver로 신규생성계정으로 접속하니 권한이 없어 select도 못하는 상황이 존재했다. 이후에 권한문제임을 깨닫고 접속 자체를 신규계정으로 접속, create table 명령어를 수행하는 방식으로 재설정했다.

3. PostgreSQL 데이터 베이스 백업 및 복구

임시데이터들도 모두 갖춰졌겠다, 이젠 해당 데이터베이스 설정 및 파일들을 모두 tar 압축백업을 할 예정이다.

그리고 신규 서버에 OS 설치 후 이걸 고대로 갖다 놓았을 때 정상적으로 접속이 되는지 확인할 것이다.

아마도 PostgreSQL 버전이 같다면 큰 문제 없이 수행되리라 예상하고 있다.

일단 PostgreSQL 설정파일 및 데이터베이스 파일이 위치해있는 디렉토리로 이동, tar 압축을 수행한다.

생성된 tar파일을 고대로 다운로드 한 후, 신규 서버에 업로드한다.

https://kimfish.tistory.com/361

이 내용을 참조하여 신규 서버에 PostgreSQL을 설치한 후, tar 파일을 업로드 한 이후, 다음의 과정을 수행한다.

뭐 그런데 결과가 당연하게도, 잘 구동 되었다.

문제는 기존 PostgreSQL 설정파일의 위치나 데이터베이스 파일, 테이블 스페이스 경로 등이 커스텀화 되지 않았는지 파악하는것이 가장 중요하다.

다음에는 직접 PostgreSQL 서버에 접속 후, 각종 테이블스페이스와 데이터베이스 설정 위치들을 쿼리를 통해 알아볼 예정이다.

얼마전에 docker linux에 PostgreSQL13 Server를 설치하였고 DBEaver를 통한 접속테스트를 수행했다.

이번에는 신규 계정 생성 및 TableSpace 생성, 기본적인 임시 테이블 서너개를 생성 후 백업 테스트를 위한 준비를 수행해볼 예정이다.

DB의 admin 계정으로 접속해서 직접 쿼리로 관리해도 되지만, 이번에는 새로운 방법(?)으로 해보려 했다.

아래의 순서는 다음과 같다.

데이터베이스 설정 - 테이블스페이스 설정 - 계정 생성 및 권한 설정

1. psql 접속 

docker linux에 접속 후, postgres 계정으로 변경한다.

이후, 설정에 따라 다르지만 아래의 명령어를 통해 psql에 접속한다.

2. 데이터베이스 설정

이제 막 PostgreSQL을 설치했으므로 기본 데이터베이스 외에는 존재하지 않으므로, 데이터베이스 생성부터 수행한다.

다음과 같이 명령어를 입력한다.

create database [DB명];

\l 명령어는 생성된 database를 확인하는 명령어이다.

3. DB 계정 생성 및 권한 부여

여기까지 기본적인 PostgreSQL 설정이 모두 완료되었다.

DBEaver를 통해 접속했을 때 정상적으로 보여지는 것 또한 확인했다.

Docker에 설치된 RockyLinux 8.10 버전에 PostgreSQL 13을 설치 후 데이터 이관 테스트를 진행하려 한다.

Docker에서 PostgreSQL 13을 설치할 때에는 몇가지 추가로 설정해줘야 할 것들이 있어 정리할 겸 작성한다.

Docker에서 설치할 때의 에러 및 해결방법을 같이 작성하니, 일반 서버OS(Docker가 아닌)에서는 불필요한 내용도 다소 존재한다.

1. PostgreSQL Repository 등록

다음의 명령어로 공식 Repository를 등록한다.

yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm

위 오류는 GPG 서명검증 실패 오류로, 다음의 명령어로 재시도한다.

yum install -y --nogpgcheck https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm

2. 기본 PostgreSQL 모듈 비활성화

RockyLinux 8.10 버전에서는 기본 PostgreSQL 모듈 활성화가 되어있으니, 비활성화 작업을 거친다.

이 작업은 약간의 시간을 소요한다.

yum module disable -y postgresql

3. PostgreSQL 13 Server버전 설치

이제 PostgreSQL 13 Server를 설치한다.

yum install -y postgresql13 postgresql13-server

4. PostgreSQL 설정 및 구동

PostgreSQL DB 초기화 및 권한과 관련해서 설정을 진행해주어야 한다. 다음의 명령어를 수행한다.

4-1. PostgreSQL DB 초기화

해당 디렉토리가 존재하지 않는다면 해당 디렉토리를 생성한다.

존재한다면 이 단계는 건너뛰어도 된다.

4-2. postgres 계정 권한부여 및 계정전환

PostgreSQL 13 을 설치하면 postgres 라는 계정이 생성된다. 해당 계정으로 PostgreSQL13을 구동하는 등, PostgreSQL 기능과 관련된 여러 동작을 수행한다.

해당 계정에 위 4-1. 디렉토리의 접근권한을 부여해준 후, 해당 계정으로 접속한다.

4-3. DB 클러스터 초기화

postgres 계정으로 아래의 명령어를 수행하여 DB 클러스터를 초기화해준다.

4-4. PostgreSQL 실행 및 중지

아래의 명령어를 통해 실행 또는 중지한다.

/usr/pgsql-13/bin/pg_ctl -D /var/lib/pgsql/13/data start 

/usr/pgsql-13/bin/pg_ctl -D /var/lib/pgsql/13/data stop

로그는 /var/lib/pgsql/13/data/log 경로에 위치해있다.

5. 호스트 PC에서 접속하기 위한 설정

Docker에서 PostgreSQL을 구동시켰으니 호스트PC인 Windows 에서 DBEaver를 통해 접속하려 한다. 꽤 많은(?) 삽질이 필요했는데, 아래의 방법을 진행하여 연결에 성공했다.

5-1. 접속 포트 설정

현재 Docker는 18081 포트로 포트포워딩이 설정된 상태이다. postgreSQL은 5432 포트가 기본포트이므로, 아래의 설정파일을 편집한다. 모든 과정은 postgres 계정으로 진행한다.

아래 항목 중, listen_address 항목을 모든 IP주소인 '*' 로 설정하고, port는 5432 에서 변경할 포트인 18081로 수정한다.

기본적으로 주석처리가 되어있으므로 주석 또한 해제한다.

postgresql 서버를 재시작해야 설정이 적용된다.

5-2. 외부 접근 허용 정책 설정

외부 접근을 허용하는 정책을 설정하기 위해 같은 디렉토리에 있는 pg_hba.conf 파일을 열어준다.

최하단의 볼드체로 표시된 항목 두 개를 추가한다.

postgresql 서버를 재시작해야 설정이 적용된다.

5-3. 기본계정 postgres 비밀번호 설정

어디에선가 본 것으로는 postgres 계정의 비밀번호는 postgres라던데 사실 아니었나보다 -_-;

그래서 직접 접속 후, postgres 계정의 비밀번호를 설정해준다.

위 5-1. 항목에서 5432 포트를 18081로 변경하였기 때문에, 기본 접속 명령어인 psql  명령어가 오류가 나게 된다.

이럴 때에는 당황하지 말고 변경한 포트설정 옵션을 넣어주어야 한다.

접속이 되었다면 아래의 쿼리를 입력하여 비밀번호를 설정해주자.

그리고 DBEaver 에서 접속하면 정상적으로 접속됨을 확인할 수 있다.

DB를 로컬 Windows PC에는 많이 설치해보고 개발용으로 설정한 적은 많아도, Docker Linux에 세팅한 후 접속해보는 건 처음인것 같다. 여러모로 설정이 많아 헷갈리기도 하고 조금 많이 어렵기도 했다. 실제 Linux 서버에 설치하는건 조금 다를것이고, 보안을 고려한다면 외부 접속 설정 정책 부분도 손을 좀 더 봐야 할 것으로 예상된다. 뭐, 그래도 해본게 어딘가 싶긴 하지만 말이다.

개발서버로 쓰던 CentOS 가 지원중단이 되면서 RockyLinux로 OS를 변경하게 되었다.

SVN 도 이관대상이기 때문에 이전글에서 개인 놋북에 Docker로 RockyLinux를 설치 후 SVN 설정까지 모두 완료했었다.

[RockyLinux] svn 설치 및 실행, 연동까지. - https://kimfish.co.kr/359

이번에는 이론상으로 생각해보던 SVN Repository를 tar 압축 후, 신규 서버에서 압축해제 했을 때 정상동작 하는지를 테스트 해보고자 한다. 스포일러를 조금 하자면, 같은 버전이라면 그냥 뭐 된다. 예상했던 결과이긴 하지만.

다른 버전의 경우에는 어디까지 호환되는지 궁금하긴 한데, 지금 이관 규칙 자체가 최대한 같은 버전이기 때문에 큰 문제의 여지는 없다고 판단된다.

1. SVN 저장소 경로 확인 및 tar 압축

리눅스 SVN 저장소는 저장소 디렉토리 하위에 SVN 설정들이 포함되어있는 형태로 구성된다. 이걸 통째로 압축하고, 신규 서버에서 동일하게 압축해제하면 될거라는 판단이 든다. 저장소 디렉토리를 확인 한 후, tar 압축을 수행한다.

2. 신규 서버에 tar 압축해제 및 구동

svn_repo.tar 파일을 신규 서버에 업로드 후, tar 압축해제를 수행한다.

이제 svn 구동을 수행한다.

3. Tortoise SVN Repo-Browser 확인

Tortoise SVN 으로 접속해서 기존 서버에서 생성한 사용자계정 및 Commit 된 이력을 확인한다.

4. 결론

그냥 뭐 잘 된다... 문제는 현재 기동중인 SVN 서버의 저장소 경로가 어디냐는 것이긴 한데, 이걸 파악하는게 먼저일것 같기는 하다.

사실 생각해보면 당연한게, SVN 설정의 모든부분(계정/Commit파일/메세지/권한/설정 등)은 SVN 저장소 경로의 하위에 모두 담겨있기 때문이다. 

RockyLinux에 SVN을 이관설치할 일이 생겼다. 아직 플젝 투입 전이라 외부에서 겸사겸사 테스트해보느라 쓰는 글.

대충 환경은 다음과 같다. Windows PC에 docker로 RockyLinux8.10을 올리고, 여기에 svn을 설치해서 Windows에서 테스트 해보는 식으로 진행해보았다.

기본적인 명령어는 생략하고, SVN 위주로 작성해본다.

1. SVN 설치

yum install -y subversion

2. SVN 저장소 디렉토리 생성 및 저장소 생성

2-1. mkdir [저장소 디렉토리]

정해진 규칙은 크게 없어보이나, 나는 루트 디렉토리에 만들어주었다.

2-2. svnadmin create [저장소 디렉토리]

해당 명령어를 입력하면 별다른 메시지가 출력되지는 않지만, 디렉토리에 들어가보면 SVN 관련 파일이 생성되어있음을 확인할 수 있다.

3. SVN 설정 변경 

3-1. SVN 구동설정 변경

conf 디렉토리 하위의 svnserve.conf 파일을 변경해준다.

설정 파일이 매우 길어서 찾아서 변경하는것이 빠르다.

각 파라미터별로 주석이 되어있는 것들을 찾아 주석을 해제한다.

주의할 점은 단순히 주석만 삭제할 것이 아니라, 각 파라미터 앞의 공백문자열(스페이스바)도 제거해주어야 한다. 이걸로 삽질을 몇시간이나 했던지;

3-2. SVN 계정 생성

SVN에 접속가능한 계정을 생성한다. 계정별 권한도 부여가 가능한데 이건 좀 더 나중에.

알아보니까 리눅스에서는 VisualSVN이 지원되지 않아서, 직접 계정별 권한을 생성해줘야 한다고 한다 -_-;

conf 디렉토리 하위의 passwd 파일을 변경해준다.

나는 test 계정에 test12!@ 비밀번호로 설정해주었다.

4. SVN 구동 및 확인하기

svn 구동은 다음과 같은 명령어로 수행한다. 

svnserve -d -r [저장소 디렉토리] --listen-port [사용포트] --log-file [로그디렉토리/파일명]

로그 및 포트를 변경하지 않는다면 해당 부분의 옵션은 사용하지 않아도 무방하다.

SVN에 왜 기본 로그를 사용하지 않는지는 조금 의문이긴 한데, 아무튼 해당 로그 디렉토리에 가보면 구동에 성공했다 뭐다 별로 표시도 안난다.

그러니까 직접 Windows PC 에서 SVN에 접속해보자.

SVN 툴로는 TortoiseSVN을 많이 사용한다. 난 이미 설치가 되어있다.

docker에서 띄웠으니 localhost 로 작성하고, docker는 18081로 포트포워딩 된 상태이다. 위에서 SVN은 18081로 커스텀포트를 지정했으니 이렇게 설정하고 접속하면 된다.

만약, svn 포트를 지정하지 않았다면 (버전에 따라 다르지만) 3690 포트를 사용하게 된다. 그렇다면 docker도 포트포워딩을 3690으로 해줬어야 같은 환경에서 접속이 가능할 것이다.

정상적으로 접속에 성공하면 별다른 메세지 없이 바로 실행된다. 겸사겸사 위에서 띄워둔 로그를 보면 뭔가 길게 잔뜩 있다.

이제 커밋을 해보자. 잘 올라가는지.

5. SVN 커밋

제대로 하려면 IDE 세팅하고 직접 소스코드 커밋도 해보고 그랬을텐데, 내가 하려는 것은 SVN 디렉토리 백업이 정상적으로 동작하는지를 보려는 것이기 때문에 이 과정은 생략했다. 그냥 파일 커밋을 하고 이게 디렉토리로 복붙해도 잘 되는지만 보면 되니까.

SVN Repo-Browser에서 마우스 오른클릭 후 Add File를 선택한다. 그 후에 아무거나 파일을 선택해서 커밋하면 된다.

깜빡하고 계정정보 입력하는 부분을 캡쳐하지 못했는데, 위의 3-2. SVN 계정 생성 에서 생성한 계정 정보를 입력하면 된다. 그럼 커밋 완료. 서버로그도 같이 확인한다.

대충 업로드가 다 되었다. 이로써 기본적인 SVN 설치, 설정, 연동까지 수행했다.