svn 사용법 중에
글쓴이: auditory / 작성시간: 월, 2008/07/28 - 11:20오전
tortoisesvn 사용하고 있습니다.
version된 파일 중에 일부 파일들은 checkout할때는 서버에서 가져오지만
local에 변경사항이 있어도 무시하고, commit할 내용이 없는것처럼 보이고,
실제 commit시에도 무시하고 싶은데요.
가능할까요?
Forums:
tortoisesvn 사용하고 있습니다.
version된 파일 중에 일부 파일들은 checkout할때는 서버에서 가져오지만
local에 변경사항이 있어도 무시하고, commit할 내용이 없는것처럼 보이고,
실제 commit시에도 무시하고 싶은데요.
가능할까요?
svn 을 이용하는
svn 을 이용하는 방법은 아니지만 일반적으로 이련 경우는 그런 파일들을 묶어서 example.tar 같은 묶음 파일로 배포한든지 해서 사용자가 필요하다면 풀어서 안에 있는 파일들을 보고 변경하고 싶은 대로 변경하도록 하면 묶음 파일 자체는 저장소에 바이너리로 등록이 되어 있지만 풀어서 생긴 파일들은 어차피 저장소에 등록된 파일이 아니니 일부러 저장소에 추가하지 않는 한 변경사항이 추적되지도 않겠죠.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
님께서 말씀하신
님께서 말씀하신 방법이 거의 정답이군요.
svn 홈페이지의 faq에서도 비슷하게 템플릿 파일을 쓰라고 합니다.
새로나온 1.5 에서는 checklist 중에 ignore-on-commit 기능이 있는데,
이 경우 로컬에서 변경사항은 추적되고 commit 할때만 디폴트로 체크가 안되고,
또 로컬에서만 관리된다는 문제가 있네요.
checkout 할때 템플릿 파일을 다른이름으로 자동으로 카피한다든가,
압축을 자동으로 푼다든가 하는 기능을 svn server의 hook에서 구현할 수 있는지 살펴봐야겠네요.
답변감사합니다.
이런경우는 branch 및
이런경우는 branch 및 tagging 을 활용하도록 노력하십시오.
svn 은 소스를 local 에서 고친걸 무시하고 어쩌고 이런용도로 접근할 것이 아니라...
내가 혼자 고쳤더라도 그 혼자 고친내용을 전부 keep 하고 그때마다 logging 하려는게 목표입니다.
개인 branch를 놓고 영구 tagging 하시면 원하시는 목적에 충분히 부합 할 수 있습니다.
실제 commit에 특정파일만 무시하고 싶으시다면, 1.5의 버젼을 사용하는게 정석이고요.
svn 기능의 조합만으로 충분히 원하시는것을 얻으시면서 개인적으로도 소스관리가 가능합니다.
언제나 본인의 기억이 지속될 것이라고 절대 믿지 마십시오. 개인적으로 적용한 수정이나 패치도 언제나 기록이 되도록하십시오.
좋은 개발 습관의 기본입니다.
Neogeo - Future is Now.
Neogeo - Future is Now.
이런경우가 필요한게
이런경우가 필요한게 아래 링크처럼 개인사용자별로
자동으로 빈번하게 수정되는 파일의 경우입니다.
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-commit.html#tsvn-dug-commit-ignore
또는 visual stuio만 해도 solution 파일외에 개인별 설정을 저장하는 파일을 따로 만들기도 합니다.
여기에 branch를 쓸수는 없겠죠.. ^^
ignore-on-commit 기능이 현재로서는 최선처럼 보이지만,
결국 각 사용자별로 로컬에서 설정해야한다는 문제가 있습니다.
tortoisesvn을 쓰는 경우에 오버레이 아이콘만 봐서
필요한 모든 내용이 서버에 반영된 상태인지 확인하기도 어렵다는 단점도 있고요.
그런 파일은
그런 파일은 처음부터 commit 하시면 안되는 파일입니다.
자동으로 빈번하게 수정되는 파일류는 애초부터 check out시에 들어오지 않도록하는게 원칙입니다. repos 에 남겨서도 절대 안되구요.
당연히 수동으로 수정되는 부분을 keep 하는것이고 그것에 대한 log 를 남기는 것이지, 자동으로 gen 되는 파일은 애초에 custom build 에 생기는 것이더라도
commit 하시않는것이 원칙입니다.
( 중간 결과물인 lib , obj 등 처럼 취급하십시오. )
애초에 commit 하지 않으면 아예 자동으로 무시됩니다. 그게 기초중에 기초이구요 :)
실제 업무에서 custom build 로 생성되는 중간 결과물 같은것이나 ( auto gen header 파일이나 )
obj , lib 또는 vs temp 파일들을 commit 하셨다간 아주 -_- 사수에게 박살날겁니다.
'손으로 직접 작성하시는 파일이나 바이너리에 대해서만 commit 하시고 고정되어있는 bin 의 경우도 소스로 얻어지는 결과물을 제외하고만 commit하십시오.'
애초에 commit 하실필요 없는걸 commit 하셔서 쓸데 없는 고민을 하신것 같군요 :)
Neogeo - Future is Now.
Neogeo - Future is Now.
첨부해드린 링크는
첨부해드린 링크는 안 읽어보신거 같군요.. ^^
저만의 문제가 아니라, svn FAQ에 올라와 있는 문제입니다.
자동으로 빈번하게 수정되는 파일이 co 시 들어와야하는 경우가 *절대* 없다고
보장할 수는 없겠지요.. ^^
음 제글을 정확히
음 제글을 정확히 다시 설명해 드리겠습니다.
위와 아래글을 조합하시면 충분히 이해가 되실 겁니다.
상황상
'반드시 서버에 원본은 있어야 하고 쓰다보면 자주 바뀌는 파일'
이런녀석은 특정버젼으로 tagging 해두시고 다른 디렉토리에 넣어두십시오.
그리고 그 버젼을 soft link 하셔서 본인 프로젝트 디렉토리에 사용하십시오.
위의 링크에는 전혀 관계없는 내용만 보였습니다. ( 다 읽어보았습니다. )
예를 드신 vs 의 temp 파일 ( suo 등등 ) 은 *절대* 들어와선 안될 내용입니다. 본인이 예제를 잘못 들어주신거지요 :)
다시 바로 위가 아닌 처음에 단 제 답글을 참고하셔서 상황을 판단하시면 됩니다.
윗글도 자동 생성되며 소스나 컴파일 중간결과물 파일을 *절대* 올려서는 안된다는 것이지 애초에 처음에 원본이 필요한 ( 소스만으로 생성이 되지 않는 )
파일을 올리지 말라고 한적은 없습니다. vs temp 의 예를 드셨기때문에 설명을 그렇게 한 것입니다.
왜 제가 이렇게 압축에 반대하는가 하면,
우선 압축된 파일을 풀어야 전체가 build 되는것은 일단 build 에 단계를 더해야 하므로 직관적이지도 않고, ( 설명서를 넣어뒀더라도 ) 보통의 사상에 어긋납니다.
( joel test 를 참고하십시오. 즉시 build 나 auto build 를 만드실려면 더욱 그렇습니다. )
그 압축된 파일에 뭐가 들었는지 직관적으로 알수도 없습니다.
압축된 파일내의 여러파일을 고칠때 어떤내용을 어떻게 고쳤나 알기도 힘듭니다. ( diff 가 안떠지겠죠? )
윈도우즈에선 soft link가 안되요! 라고 생각하신다면 junction.exe 를 활용하십시오. ( msdn 의 예제도 읽어보십시오. )
그리고 그러한 파일들은 작업 directory 에서 commit 목록에 애초에 넣지 않는게 정석입니다.
:) svn 을 꽤 오랫동안 현업에서 사용중입니다만 zip 파일 같은것으로 관리한적은 한번도 없습니다.
1. 각 파일별로 버젼을 관리하며 수정사항을 반드시 로깅하기 위해 svn 을 사용하기 때문이며,
2. 신입이던 누구던 일을 처음에 시작하면 해당 프로젝트의 repos. 에 접근하여 바로 one time 에 build 해보려고 시도할 것입니다. ( 메뉴얼 읽기 전에 )
3. repos. 는 그 이름과 디렉토리 구조만으로도 충분히 소스파일의 상태와 여러가지를 설명할 수 있어야 한다입니다.
다시 한번 상황을 곰곰히 생각해보시고 해당 파일을 commit 하는 디렉토리에 꼭 두어야 하는가, soft link 만으로는 해결되지 않는가 생각해보십시오.
( 그런데 제가 개발을 수년간 해오면서 자동으로 수정되는 파일이 자동으로 생성도 되지 않으면서 ( 즉 원본이 있으면서 ) 프로젝트에 디펜던시를 가지는 경우는
한번도 본적이 없었습니다. 도대체 무슨 파일인가 심히 궁금하군요 자세히 알려주시면 좋겠네요 :) )
다른 분들이 비슷한 상황에 zip 을 solution 으로 사용하신뒤 진정한 소스관리의 철학에 어긋난 방식을 고수하시게 될까봐 우려하여 글을 남깁니다...
Neogeo - Future is Now.
Neogeo - Future is Now.
"자동으로 수정되는
"자동으로 수정되는 파일이 자동으로 생성도 되지 않으면서 ( 즉 원본이 있으면서 ) 프로젝트에 디펜던시를 가지는 경우"
알려드린 링크에 있는데요..
"IDE 에서 사용하는 프로젝트 파일인데, time stamp를 기록하는경우."
저도 어떤 IDE가 이런 짓을 하는지는 모르겠지만,
이런 파일을 versioning하는것이 사용자의 미숙함에서만 나오는것은 아니라는 것을 말씀드린것입니다.
아 물론 solution 파일은 제가 좀 예를 잘못 들긴 했습니다.
.sln파일은 versioning하고,
개인 사용자의 파일은 안하는게 맞겠지요.
그런데 vs2005의 경우에는 debug setting (명령행인수, 작업디렉토리) 정보는
클라이언트마다 별도의 파일에 저장됩니다. 이런 파일은 좀 애매하죠.
기록해야할 정보긴한데, version하지는 않아야하는 경우라고 봅니다.
그런데 제가 현재 처한 사항은 좀 다른 경우긴합니다.
외부에서 만든 lib를 사용하는데, 이 lib에서 외부파일에 적힌 param을 읽습니다.
그리고 실행하면서 이 내용을 계속 바꿉니다.
그런데 이 파일이 없으면 에러가 납니다.
물론 lib를 바보같이 짠 케이스이긴 하지만 어떡합니까.
그래도 관리는 해야지요.. ^^
전형적인 ini파일 -
전형적인 ini파일 - read - write 패턴이군요. ( 전 바이너리 인줄 알았습니다. 죄송합니다 그래서 링크가 관계 없다고 여겼습니다. )
soft link 면 간단히 해결되시고 모든 문제가 없습니다. ( 낮은 SVN 버젼도 ) junction.exe 를 참고하십시오!\
IDE 에서 바꾸는 경우도 ( custom build 에 예제에 가까울 겁니다. ) soft link 면 다 해결됩니다. tagging + soft link 혹은 아주 가끔 그 파일을 꼭 고쳐야 된다면 (이런 경우 더더욱 버젼 관리가 필요하겠죠! ) branch + soft link 로 해결하십시오.
zip 은 근본적인 해결책이 아니라고 생각합니다.
debug setting 중 디렉토리 정보는 반드시 상대경로로 되어야합니다. 디렉토리 정보가 클라이언트마다 별도로 필요할 상황이면 약간 문제가 있을 수 있다고 생각합니다.
data 나 명령행인수 자체를 다르게 놓고 하는 디버깅 세팅정보( 혹은 디렉토리 정보 )는 반드시 따로 vs build profile을 별도로 작성해서 commit 하다가, 필요없어질때 지우면 됩니다.
( 예를 들어 vs 의 빌드 환경중 DEBUG 를 상속받아 -> DEBUG_XXX 라고 만든뒤 이를 저장하고 commit 계속 하는게 맞다고 봅니다. 다른 사람은 그 XXX 버젼으로는 굳이 build 할일이 없겠죠. )
-_- 그나저나 제가 일하는 원리원칙 방식을 하나씩 자꾸 강요하는거 같아서 죄송합니다....
( 경험상 이게 결국은 편하더라~ 카는 이야기 이니 너무 기분나쁘게 듣지는 마십시오.. )
Neogeo - Future is Now.
Neogeo - Future is Now.
다시한번 링크를
다시한번 링크를 드리는데요..
http://subversion.tigris.org/faq.html#ignore-commit
결국 님께서 말씀하시는 내용도 위 링크의 내용과 같은것 아닌가요?
.zip을 사용하는것은 답글자분의 아이디어였고,
unzip을 쓰느냐, normal copy를 쓰느냐 symbolic link를 쓰느냐의 문제인것 같습니다만..
vs2005에서 debug setting은 .sln파일이나 .suo파일에써지는게 아니라
.vcproj.pcname.username.user 파일에 써집니다.
이런파일을 versioning하느냐 안하느냐는 개인에 따라 다르겠지요.
물론 이 경우는 어차피 사용자마다 pc마다 이름이 다르니 상관없겠구요.
-ㅅ- 음 끝까지
-ㅅ- 음 끝까지 설명을 해야겠군요.
말씀하신 설정 파일이 lib 의 버젼과 함께 update 되었을 경우를 상상해 보십시오.
제시하신 3가지 방법중에 어느것이 가장 좋은가 생각해보시면 답이 보이실 겁니다. ( 전 절대 변하지 않을거 같았던 ini 가 외부회사에서 말없이 바꾸어 새 버젼을 던져주어
회사내의 모든 사람이 삽질했던 경험이 있습니다. 그 lib 을 update 해야하는 프로젝트버젼이 있고 안해야 하는 프로젝트버젼이 있다면, 그리고 그것을 한방에 bat 파일이나 다른 스크립트로 빌드하길 원한다고 상상해 보십시오. tagging 이나 branch 따로 안해뒀다간 rev 뒤적거려 copy 하는것을 새로운 사람이 입사할때마다 해야할 것입니다. )
결코 unzip 쓰느냐, normal copy 쓰느냐 , symbolic link 쓰느냐의 문제가 아닙니다.
그런 파일도 요는 버젼관리가 반드시 되어야한다는 가정하에 가장 편했던 방법을 말씀드리는 것입니다. ( zip 자체도 rev 따로 tagging 해 두신다고 하더라도 안에 파일이 많은 상황이라면, 그리고 그 파일중 일부가 바뀐거고 어느 포맷이 어떻게 바뀐건가 diff 를 떠보고 싶다고 가정하면.. )
build 때마다 copy 되게 하는것도 방법입니다만, 전 symbolic link가 편했던게 한군데만 변경을 적용하면 연결해둔 모든 프로젝트에서 해결이 되었기 때문입니다.
( 기본적으로 항상 소스코드던 파일이던 copy 자체를 그다지 좋게 보지 않는 주의입니다. 주변이 자꾸 변하는 환경일수록 그렇습니다. )
debug 관련 속성은 2005 이상버젼에선 말씀하신대로 입니다.
제가 잘 못 이야기를 드렸군요. 죄송합니다.
Neogeo - Future is Now.
Neogeo - Future is Now.
댓글 달기