svn 이상한점 한개....
글쓴이: doodoo / 작성시간: 수, 2010/10/20 - 12:18오후
mplayer 를 새로 컴파일 하고 있었습니다.
전에 r31930 버젼에서 이번에 r32517 버젼으로 svn update 를 통해 업데이트를 했는데
이것이 libass/ass_mp.h 가없다는 에러와 함께, 컴파일이 않되는겁니다.
그 디렉토리안에 ass_mp.d 라는 파일에 ass_mp.h 가 기록되어 있더군요
결국 mplayer 디렉토리 싹 날리고 svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer
해서 다시 다 가져 왔습니다. 이건 되더군요...
업데이트 하면 원격지의 파일이 없어지면 로칼에 파일이 같이 사라져야하고 바뀐것이 있으면
같이 업데이트 되어야 하는것 아닙니까?
Forums:
리포지터리에 파일이
리포지터리에 파일이 없고 자신의 로컬에 파일이 있을 경우 충돌아닌가요..?
위대한 한글
위대한 한글
그면 그 경우에
그면 그 경우에 로컬의 파일이 업데이트 하면서 삭제 되어야 하는것 아닌가요?
이경우 보통 수동으로 충돌 해결 해 주어야 하나요?
없데이트시에 아무런
없데이트시에 아무런 메시지도 안나왔나요?
위대한 한글
위대한 한글
네 아무것도
네 아무것도 없었습니다...
반대의 경우 삭제 하지 말아야 되는 경우에
자동으로 삭제하면 님께서는 당연하다 생각하시면서
백업해 둔 곳에서 다시 복사 하실 건가요? ^.^
정잭 나름이겠지요 ㅠㅠ
---------------------------------------------
git init
git add .
git commit -am "project init"
---------------------------------------------
---------------------------------------------
git init
git add .
git commit -am "project init"
---------------------------------------------
근데...저 같은
근데...저 같은 경우에는 제가 직접 mplayer 소스를 고쳐서 사용하는것도 아니고,
낮은 버젼의 것을 그냥 컴파일 해서 mplayer 바이너리만 만들어서 쓴것인데
이번에 svn update 를 하고 나니 소스가 수정(그것이 Makefile 이건 ass_mp.h 이건)이
원격 리포지터리에서 되면 여기서도 원격과 같이 동기가 되어야 하지 않겠느냐 하는거죠.
님께서 수정하던 안하던 간에 그냥 최신 버전의 바이너리만
다시 빌드 해서 쓰실 생각이라면 그냥 따로 체크아웃해서 사용하는데
맞다고 저는 생각이 듭니다만.. 뭐가 정답인지는 저도 모르겠습니다.
--------------------------------------------
git init
git add .
git commit -am "project init"
---------------------------------------------
---------------------------------------------
git init
git add .
git commit -am "project init"
---------------------------------------------
당연히 동기가
당연히 동기가 됩니다. 관리 대상에 들어있는 것들만.
ass_mp.d 가 동기되지 않았다면 관리대상에 들어있지 않은 파일일 것이고,
이름으로 봐선.. 아마도 의존성 검사 목적으로 컴파일 타임에 만들어지는 파일일텐데,
ass_mp.c 로부터 만들어지면서 정작 ass_mp.c 와의 의존성이 설정되지 않았나보네요.
ass_mp.c 가 변경되면 자동으로 ass_mp.d 도 갱신되어야 하는데 그게 안되어서 잘못된 의존성 정보때문에 make가 컴파일 에러를 발생시킨 거겠죠.
어지간히 복잡한 놈이 아니면 이렇게까진 하지 않는데...
하여간 ... 수동으로 할 수도 있고 make 에 맡기는 방법도 있습니다.
허술하지만... 예를 들면
[bushi@rose live]$ cat t.c #include <stdio.h> #include "t.h" [bushi@rose live]$ [bushi@rose live]$ cat t.h #include <string.h> [bushi@rose live]$ [bushi@rose live]$ cat Makefile CFLAGS = -O2 OBJS = t.o DEPS = ${OBJS:.o=.dep} $(OBJS): %.o: %.dep $(DEPS): %.dep: %.c $(CC) $(CFLAGS) -M $^ -o $@ clean: @rm -vf ${OBJS} distclean: clean @rm -vf ${DEPS} -include $(DEPS) [bushi@rose live]$ [bushi@rose live]$ make t.o cc -O2 -M t.c -o t.dep cc -O2 -c -o t.o t.c [bushi@rose live]$ [bushi@rose live]$ make t.o make: `t.o'는 이미 갱신되었습니다. [bushi@rose live]$ [bushi@rose live]$ touch t.h [bushi@rose live]$ make t.o cc -O2 -c -o t.o t.c [bushi@rose live]$ [bushi@rose live]$ touch t.c [bushi@rose live]$ make t.o cc -O2 -M t.c -o t.dep cc -O2 -c -o t.o t.c [bushi@rose live]$OTL
...
설명으로 봐서는...
원래 빌드 중에 생성되는 파일이라서 커밋하면 안되는데 코드를 고치던 사람이 실수로 소스코드와 함께 커밋해 버린 것 같네요.
해결책은 해당 코드 관리자에게 메일을 보내서 "이 파일 잘못 올라간 것 같으니 날려주세요"라고 하는 것?
설령
설령 그렇더라도,
빌드시스템에 버그가 없다면 재빌드 중에 다시 생성될테니 컴파일 에러를 볼 일이 없어야합니다.
OTL
댓글 달기