'어장관리 목록'에 해당되는 글 319건

얼마전 알리익스프레스에서 yaml 기반으로 동작하는 매크로 키보드를 구매해서 사용하다가, 본격적으로 커스텀 매크로를 작성해서 사용하면 어떨까? 하는 욕심이 올라왔다. 해당 키보드의 경우에는 키 하나에 대략 5가지의 조합키를 매핑할 수 있었지만, shift 라거나 마우스 클릭과 같은 특수동작 매핑은 불가능했다. 그러다가 결국, 오래전부터 알고지낸(?) QMK/VIA 커스텀 키보드까지 알아보게 되었다.

87배열의 QMK/VIA 커스텀 키보드를 새로 추가해서 사용하기에는 부담스러웠고 그냥 자그만한 매크로 키보드를 구매하고자, 알리익스프레스를 뒤져보았더니 15키 + 3노브 커스텀 키보드가 존재했다. 좋아, 이번 장난감은 이거다.

3Knob+9Key, 1Knob+6Key, 3Knob+15Key 키보드 외에 회사에 1Knob+3Key 키보드도 있다. 대체 커스텀 키보드가 몇개인지원.

이번에는 RGB 뿜뿜하면서 화려하게 즐기고 싶어, 투명 아크릴 하우징으로 된 3Knob + 15Key 조합으로 구매, 말로만 듣던 VIA 부터 세팅해보려고 했으나 여러 문제에 닥치게 되었고, 이하 기본적인 QMK/VIA, VIAL 사용기를 나중에 리마인드하기 위해 작성해보고자 한다.

0. 개념잡기

1. QMK MSYS 설치부터 설정까지

뭐가 되어도 일단 설치부터 해야한다. 다음의 사이트에서 클라이언트를 다운로드한다.

- 설치가이드 : https://msys.qmk.fm/guide

- 설치사이트 : https://github.com/qmk/qmk_distro_msys/releases/tag/1.10.0

QMK MSYS를 설치하고 실행하면 터미널 창이 하나 열린다. 여기에서 다음과 같이 명령어를 입력한다.

해당 명령어는 기본적인 qmk 설치를 위한 준비단계로, 꽤 오랜 시간동안 설정이 진행된다.

setup 단계는 대략 다음과 같이 진행된다.

2. QMK MSYS - Git Clone

QMK MSYS 의 설정이 모두 끝났다면 Git에 등록된 키보드 오픈소스 펌웨어를 로컬 리포지토리에 복제해야한다. git 사이트에서 zip으로 압축받는 것은 하위 상관관계의 라이브러리 종속성 문제가 있을 수 있으니 꼭 다음 명령어를 통해 git clone을 수행해야 한다. 다운로드 받고자 하는 경로로 가서 아래의 명령어를 수행한다.

git clone --recursive https://github.com/vial-kb/vial-qmk.git

다음 QMK MSYS 터미널에서는 다음과 같이 수행된다.

여기까지 했다면 QMK MSYS의 기본 설정과 QMK/VIA 키보드의 펌웨어 준비단계까지 모두 완료된 셈이다.

3. VIA/VIAL 펌웨어 빌드

준비단계가 모두 끝났다면 QMK MSYS에서 펌웨어를 빌드한다. 내가 작업할 키보드는 winry315 키보드로, git 저장소 내에 다음과 같이 펌웨어 소스코드가 존재한다. 다른 키보드도 git에 소스코드가 있다면 같은 방식으로 펌웨어를 찾을 수 있을 것이다.

git clone 경로는 위에서 pwd로 보여지는 경로의 하위에 생성되며, 나의 경우에는 C:\Users\KimFish 에서 git Clone을 수행했기 때문에 해당 경로 하위에 vial-qmk 디렉토리가 생성되어있다. vial-qmk 하위에 keyboards/winry/winry315/keymaps 디렉토리를 찾으면 defaults, left_numpad, vial 디렉토리가 존재하는데 이는 기본 키맵 펌웨어, 왼손 넘버패드 펌웨어, vial 전용 펌웨어로 이해할 수 있다.

각 펌웨어의 설정은 다음 단계에서 알아보기로 하고, 이번에는 VIAL 빌드를 수행한다.

컴파일 명령어는 다음과 같다. 주의할 점은 vial-qmk 디렉토리에서 수행해야 한다는 점이다.

qmk compile -j 8 -kb winry/winry315 -km vial

정상적으로 빌드되었다면 해당 펌웨어의 용량과 hex 파일이 출력된다. 설정파일에서 기능을 많이 넣게 된다면 빌드는 실패하게 된다. 맨 마지막줄의 굵은 글씨가 해당 펌웨어 hex 파일과 펌웨어 용량정보이다. 이걸 이제, QMK Toolbox로 플래싱하게 된다.

4. QMK Toolbox 플래싱

QMK MSYS 는 키보드 펌웨어를 빌드한다면 QMK Toolbox는 해당 빌드 결과물인 펌웨어를 키보드에 업로드하는 작업을 수행한다. 크게 어렵지 않다.

https://qmk.fm/toolbox

해당 사이트에서 OS 버전에 맞춰 다운로드 한 후, 키보드 연결하여 실행한다.

아무런 화면도 출력되지 않지만, 키보드의 reset 버튼(일반적으로 키보드 기판에 작게 붙어있음)을 눌러주면 화면에 다음과 같이 출력된다. 

Atmel DFU device connected (WinUSB): Atmel Corp. ATm32U4DFU (03EB:2FF4:0000)

이 메세지는 키보드에 펌웨어 업로드가 준비되었다는 의미이다. 

이제 Local file 의 Open 버튼을 클릭하여 3 단계에서 수행한 결과물인 hex 파일을 선택한다. hex 파일은 vial-qmk 디렉토리에 존재한다. MCU는 노란 글씨에서 보여지는 것을 선택한다. 나의 경우에는 ATm32U4DFU 이다.

그리고 Flash 버튼을 클릭한다.

정상적으로 Flash가 된 모습이다. 이제부터는 VIA/VIAL 에서 접속해서 사용이 가능하다.

5. VIA / VIAL

VIA 및 VIAL 모두 웹사이트 설정, 클라이언트 설정이 가능하다.

각각의 정보는 다음과 같다.

* VIA WEB - https://usevia.app/

*VIA Client - https://github.com/the-via/releases/releases

* VIAL WEB - https://vial.rocks/

* VIAL Client - https://get.vial.today/download/

이후 세부적인 설정정보들은 다음에 더 쓰는 걸로. 

회사에서 자체적으로 제작한 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로 줬는데 문제가 해결되지는 않았다.

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

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

알리에서 업무용으로 매크로 키보드를 구매했다.

구매하고나서는 셀러에게 연락해서 별도 키보드 매핑 프로그램을 전송해달라고 요청해야하는데, 이게 뭐 악성코드가 있을 줄 알고 조마조마한게 한두번이 아닌데다, 프로그램에 따라 다른데 해당 매크로 키보드의 USB 전원을 뽑기라도 하면 그냥바로 초기화가 된다거나 하는 문제가 발생하는게 한두번이 아니다.

내가 구매한 키보드는 다음과 같은 3Key 1Knob 제품이다.

그래서 구글을 뒤져보니 해외 능력자 형님께서 깃헙에 프로그램과 대략적인 사용설명서를 올려두셨다. 깃헙 바로 가보자.

https://github.com/kriomant/ch57x-keyboard-tool/releases

그리고 이를 실행하기 위해서는 USB 키보드 개발킷의 일종인 USBDK를 설치해야한다.

아래의 링크에서 설치가 가능하다.

https://github.com/daynix/UsbDk/releases

USBDK를 설치하였다면, ch57 release 에서 OS 버전에 맞게 압축파일을 다운로드 한다. 나는 Windows OS 이기 때문에 ch57x-keyboard-tool-x86_64-pc-windows-msvc.zip 를 다운로드 했다.

기본적인 설명은 메인 페이지에 다 들어 있어서 어렵지는 않고, 파워쉘을 이용해 yaml 파일을 업로드하는 방식으로 매핑이 진행된다.

간단하게 내가 사용하는 위 키보드 기준으로, 설정은 다음과 같다.

파워쉘에서의 대략적인 명령어는 다음과 같다.

./ch57x-keyboard-tool show-keys - 지원되는 키 리스트 확인

./ch57x-keyboard-tool validate your-config.yaml - yaml 설정파일 검증

./ch57x-keyboard-tool upload your-config.yaml - yaml 설정파일 업로드

일단은 내가 쓰는 키보드는 잘 동작한다. 아, 이거 도네라도 해야하나. 아무튼 참 감사한 일. 

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 설치, 설정, 연동까지 수행했다.