안준환 작성:

해당하는 디렉토리에서

svn switch http://dev.textcube.org/svn/tags/1.8 .

와 같이 하면 쉽게 버전을 변경할 수 있습니다 smile

아.. 그렇군요.. 부끄부끄;;

전에도 비슷한 질문(?)을 올린 적이 있는데, 아무래도 좀 불편해서 제안드려 봅니다.

제가 지금까지 이용했던 대부분의 프로젝트들은 trunk에 최신 stable 릴리즈의 소스코드가 들어가 있었습니다. 때문에 새로운 버전이 나오면 아무 생각 없이 svn up 명령만으로도 업데이트를 할 수가 있었습니다. 그러나 텍스큐브는 trunk에 알파버전이 올라와 있더군요.

branches는 일반 사용자가 접근할 필요는 없을 것 같고,
releases에는 각 릴리즈별 압축 파일이 들어가 있습니다.
tags에는 각 stable 릴리즈별 소스코드가 버젼 넘버로 들어가 있구요..

최신 stable 릴리즈 버전만 들어가 있는 태그를 하나 더 만들어 주실 수는 없나요?
그냥 아무 생각 없이... 아아무 생각없이 svn up만으로 최신 stable로 업데이트 하고 싶습니다. ㅜ.ㅜ

(현재는 버전 업데이트를 하려면 에로, 아니 애로사항이 많습니다. 엉엉)

아흑... prototype & scriptaculous도 괜찮은 조합인데.. (사실은 요즘 그 둘을 열심히 파고 있어서 ㅜ.ㅜ)

tags/ 에 1.7.6 버전이 아직 올라와 있지 않습니다.
부탁드려요. ^^;;

안준환 작성:

버그...라기보다는 의도된 처리인 것 같습니다. 아무래도 프로그램 입장에서는 default로 들어온 값이 문자열인지 SQL문인지 판단할 수 있는 방법이 없으니까요 roll (그리고 2.0대에서 RDBMS가 ORM으로 wrapping되면 raw SQL을 프로그램 내부에서 사용하는 것을 최소화하는게 좋지요)

필요하시다면 insert문이나 update문에서 time()으로 넣어주시면 될 것 같습니다. TC 내부에서도 아마 그렇게 처리하고 있을겁니다~

몇개 안되는거 예외처리 해주시면!! 하고 생각해 보다가 보니 아무래도 플러그인인데 그 이상의 각각의 디비에 관한 로우-레벨한 것들을 요구하는건 좀 그렇겠네요. 잘 알겠습니다!

플러그인 드라이버에서 storage 섹션을 선언했을 때 mysql의 timestamp 데이터 타입의 default값으로 CURRENT_TIMESTAMP나 CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP를 주면 정상적으로 테이블을 생성하지 못합니다. 디버깅 해보니 /lib/model/common.plugin.php에서 treatPluginTable 함수가 default값을 무조건 문자열로 인식해서 생기는 문제더군요. (1.7.5에서는 적어도 이렇습니다.)

일단 급한 것은 아니니 이런 버그도 있다는것만 참조해주세요. ^^;;

그나저나 플러그인 드라이버에서 storage 섹션을 선언해서 사용하는 것은 어느 버전부터 가능한가요? 제작중인 플러그인이 자체 테이블을 생성해서 사용하도록 하고 싶은데, 만약에 비교적 최근 버전에서만 가능하다면 테이블 생성을 수동으로 해야 할 것 같아서 말이죠. (확인했습니다. 버전별 코드 일일이 뒤져서. 1.1부터 가능하군요.)

7

(3 답글들, 아이디어 및 기능 제안에 작성)

감사감사. smile

8

(3 답글들, 아이디어 및 기능 제안에 작성)

현재 subversion 저장소가 branches, releases, sandbox, tags, trunk로 나뉘어져 있습니다.

최근에 테터툴즈를 버전 업 하면서 subversion을 이용해 향후 업데이트도 간단하게 해보자는 생각으로 정식 릴리즈 된 버전의 소스를 subversion으로부터 그대로 가져오려는데, trunk에는 제 예상과는 달리 정식 릴리즈 버전이 아닌 최신 개발버전 (1.8 버전대) 이 들어 있더군요.

한참을 찾았지만 정식 릴리즈 버전인 1.7.5를 subversion을 통해 소스 그대로 가져오는 태그는 발견할 수 없었습니다. branches/1.7의 경우는 1.7.5가 아닌 1.7.6이 들어 있고, releases에는 tar로 패키징된 파일만 들어 있습니다. tags에는 1.7.3이 들어 있구요.

그래서 (물론 프로젝트 내부적으로 결정된 사안이 있겠지만) trunk에 들어 있던 최신 개발버전을 branches로 이관하고 (branches/alpha 정도로 하면 될까요?), trunk에 정식 릴리즈 소스를 넣는게 어떨까요?

혹은 제가 릴리즈 소스를 발견하지 못한건가요? ^^

(아무튼 어쩔 수 없이 현재는 1.7.6 rc1을 사용중입니다.)

밑에 루나모쓰님과 같이 로그인이 안되는 현상 (리비전 6705) 이 발생해서 원인을 살펴보던 중에
EAF4.js
common2.js
gallery.js
..
..

등등의 js파일을 불러오는 경로가 //script/*.js로 되어 있어 http 패킷을 살펴보니 host가 script로 들어가더군요. 해당 파일을 로딩하는 파일들을 보면 $service['resourcepath']가 앞에 붙던데 이 값이 잘못 들어갔던지, 슬래쉬를 하나 더 잘못 넣은게 아닌가 생각됩니다.

물론 이걸 수정했는데도 로그인은 되질 않습니다. ㅜ.ㅜ

http://lunamoth.biz/2126

루나모스님 글 읽다가 문득 든 생각입니다만..
rewrite 모듈 없이 완전하게 같은 fancy url을 구현할 수는 없지요. 어쩔 수 없이 파라미터 구분자가 들어가긴 해야 합니다만..
좀 지저분하겠지만 이런건 어떨까요?
.htaccess에 404 에러에 해당하는 커스텀 에러 페이지를 생성하고, 해당 커스텀 에러 페이지를 request_uri을 해석하는 스크립트로 대체하는겁니다.
물론 정말 잘못된 경로가 입력되거나, 없는 페이지를 요청하려고 한다면 일반적인 404 에러 페이지를 출력하지만,
그 외에 경로에 대해선 파싱하고 정상적인 동작을 수행하는겁니다.

지저분할랑가요;;

(지금 막 로컬에서 간단하게 테스트 해봤는데, 잘 돌아갑니다!!)

lunamoth님의 http://lunamoth.biz/2112 엔트리에 답글 형식으로 푸념을 늘어 놓다가,
공식 포럼에도 건의하는게 좋을 것 같아서 옮겨 봅니다.

태터툴즈/텍스큐브의 버젼 업데이트 공개가 너무 잦다는 느낌이 듭니다.
때문에 사용했을 경우 물론 안정적이고 편리해졌지만, 외양상 문제가 많아서 자주 업데이트를 한다거나
잦은 업데이트로 인해 내 블로그에 무슨 문제가 생기지나 않을까 하는 노파심이 들기도 하네요.
업데이트 버젼 공개는 물론 개발팀의 내부 지침에 따라 이루어지겠지만,
개인적인 의견으로는 마이너 버전의 경우는 스냅샷 형식으로 개발자 포럼을 통해 공개하고
메이저 버젼만 공식적으로 공개하는게 어떨까 싶은데요.

담담한 분들이야 상관 없지만, 저같이 예민하고 강박증(?)에 시달리는 사람은
모르면 모르되 업데이트가 있는걸 안 이상 가만 있을수가 없습니다. 덜덜덜...;;

stable/beta 형식의 버전 공개도 좋을듯 싶구요. (이 경우에 저는 이상하게 stable을 고집합니다만;;)

그냥 의견이었습니다. ^^;;

올리신 글 보고 잠시 생각해보았는데, 정말 딱히 권한을 체크할 방법이 없네요;;
내가 모르는건가 싶어 레퍼런스를 봐도 깔끔하게 떨어지는게 없고..

정크 테이블을 하나 만들어서 그걸 시험삼아 먼저 변경해보는건 좀 지저분하겠죠?;;

현재 1.1.0.2 버전을 쓰고 있다가 큰맘먹고 텍스큐브 최신버젼으로 업데이트를 하기 위해

1.1.0.2 => 1.1.1
1.1.1 => 1.1.3
1.1.3 => tc-1.5.3.1

로 이미그레이션을 수행하였습니다.

큰 문제는 없었지만, 이미그레이션을 위해 다음 버젼의 프로그램을 설치하고 관리자메뉴에 접근할때
테이블 구조변경을 시도하더군요. 그런데 제 경우는 구조변경이 계속 실패하였습니다.
그리고는 다시 구조변경에 관한 이야기가 나오지 않길래 이상하게 생각하다가, 1.1.3에서 텍스큐브로 이미그레이션하기 전에
잠시 생각해보니 제가 사용하는 db의 사용자에 alter 권한이 없더군요. (현재 자체 운용중인 서버에서 테터/큐브를 돌리고 있습니다.)
그래서 큐브로 마지막 업데이트 전에 alter 권한을 주었더니 그제서야 제대로 구조가 변경되었습니다.

대부분의 호스팅 업체들은 alter 권한을 반드시 줄 것이나, 간혹 alter 권한이 없는 경우도 있을 것 같습니다.
이 경우 테이블 구조변경에 관한 언급이 다시 나오는 것도 아니어서, 혹시나 블로그 운용에 무슨 문제가 있지나 않을까 영 찜찜하더군요.

가능하다면 구조변경 시도시에 현 사용자가 alter 권한이 있는지 없는지를 체크하여 이에 맞는 추가 안내 및 구조변경 재시도가 있어야 할 것 같습니다.

제 경우 1.1.0.2에서 1.1.3까지의 테이블 구조변경이 모두 실패하였지만, 데이터는 정상적으로 이전되었고 텍스큐브에서도 현재까지는 별다른 이상은 없어보입니다.

사용환경

apache 2.0.54
mysql 4.0.24
php 4.3 (?)
tattertools 1.1.0.2

내용

http://forum.tattertools.com/ko/viewtopic.php?id=1882

에 리포팅 되었던 문제 가운데 3번 문제인듯 싶습니다.

제 경우는 아예 업로드가 되지 않았습니다.

즉, 업로드 시도 후 편집창 하단의 업로드 파일리스트 창에 표시되었던 파일이 사라지고

총 업로드 바이트 수가 0으로 표시됩니다.

혹시나 싶어 single quotation을 지우고 업로드 하니 정상적으로 되더군요.

아직 수정되지 않은 것 같아서 다시 리포팅 합니다.