나는 모든 svn : externals 참조가 다른 프로젝트의 태그 중 하나에서오고, 그 트렁크 나 어떤 브랜치에서 나오지 않아야한다는 규칙을 여기에서 확증하려고하고있다. 이것이 합당한 규칙입니까, 아니면이 접근 방식에 문제/문제점이 있습니까? 나는 안정된 개발 환경을 만들기 위해 노력하고 있으며,이 규칙으로 인해 개발이 느려지거나 어렵게 될지 궁금하다.Subversion - svn : externals은 어디에서 오는 것이 좋습니까?
"svn : externals"가있는 프로젝트는 해당 프로젝트에 대한 커밋없이 바뀔 수 있습니다. 이는 깨지는 변화를 발견하거나 좋은 버전으로 롤백하기가 어렵 기 때문에 문제입니다.
그렇습니다. 그렇기 때문에 svn : external 참조가 안정적임을 요구하는 것이 좋습니다. 태그를 참조 만 허용하면이를 달성하는 한 가지 방법이 있습니다. 또 다른 방법은 -r 구문을 사용하여 고정 된 개정판에 외부를 고정하는 것입니다. 예 from the subversion book :
타사/스킨 -r148 http://svn.example.com/skinproj
이것은 또한 태그의 변화, 내가 좋아하는 것보다 더 일반적이다 나쁜 관행으로부터 보호됩니다.
즉, 안정성과 연속 통합 간에는 여전히 의 트레이드 오프가 있습니다. 어쨌든 외부 종속성에서 변경 사항 및 버그 수정이 필요한 경우가 많습니다. 이 경우 가능한 한 빨리 CI 서버에서 종속성의 일부 변경으로 인해 프로젝트가 중단된다는 통지를 받고자하므로 문제가 최대한 빨리 해결 될 수 있습니다. 대부분의 연속 통합 서버는 외부 점검을 지원합니다.
이런 이유로 나는 (당신이 CI 서버가있는 경우에) 당신의 의존성의 간선 HEAD를 추적하는 외부에서 간선을 지키는 것이 좋다는 것을 생각한다. 태깅 할 때나 안정적인 유지 보수 지점을 만들 때 고정 된 버전으로 외부를 고정하면됩니다.
소프트웨어 개발 사례가 얼마나 성숙한 것인가에 달려 있다고 생각합니다. 변경 관리 프로세스가 있습니까? 자동화 된 빌드 및보고? 가장 안전한 방법은 프로젝트의 태그가 추가 된 빌드 (예 : lib, dll, jar 등)에 연결하는 것입니다.
외부 프로젝트에 자주 버그 수정이있는 주간 릴리스가 있으면 도움이되거나 방해가 될 수 있습니다. 좋은 구성 관리 정책이 없으면 태그에 연결하면 중요한 업데이트를 놓치기 쉽습니다. 그리고 그 의존성을 "업그레이드"하려고 할 때 많은 작업을 추가하는 많은 작은 변화가있을 수 있습니다.
비교적 안정적인 프로젝트에서 좋은 생각입니다. 유일한 문제는 모든 IDE가 소스 디렉토리가 외부 참조라는 것을 분명히하지 않는다는 것입니다. 이 경우 개발자가 해당 태그의 변경 사항을 체크인하기가 매우 쉽습니다. 내가 회상 한 바에 따르면 Subversion은 아직 "읽기 전용"을 구현하지 않았지만 이전 버전을 사용하고 있습니다.
태그에 대한 "읽기 전용"규칙이 맞습니다 - TortoiseSVN은 태그 체크인에 대한 경고를 제공하지만 AhnkSVN (Visual Studio와 통합 됨)과 같은 다른 태그는 사용자에게 경고하지 않습니다. 이것은 정말로 문제가 될 수 있습니다. –
실제로 외부를 허용하겠습니까? 당신이 옳은 이유로 그것을하고 있는지 확인하십시오. 원래 장소에서 단순히 체크 아웃하는 것, 또는 여러 위치에서 종속성을 체크인하는 것이 더 좋습니다. 나는 과거에 외부 참조에 의해 불탔습니다. 브랜치 할 경우 외부에 "동결"하지 않으면 문제가됩니다.
그러나 질문에 대답하기 위해 모든 외부가 배치되고 참조되는 특정 위치를 갖는 것이 좋습니다. 즉, 해당 위치의 내용을 제어 할 수 있다는 것을 의미합니다. 사람들은 그곳에 무언가를 놓으면 외부로 사용되어 많은 프로젝트에 의존하게된다는 것을 알고 있습니다.
외관에서 외부 사용에 대한 올바른 이유는 무엇입니까? 내 주요 이유는 여기에 재사용 목적으로 - 일반적인 프로젝트를 참조하십시오. 아니면 게시 된 dll을 사용해야합니까? –
나는 그들을 절대 사용하지 않을 외계인과 너무 심하게 불탔다. (나는 잘못된 사람이다.) 외관을 허용하는 유일한 컨텍스트는 분기/태그를 절대 사용하지 않을 때 또는 분기/태그를 수행 할 때 외부를 자동으로 고정하는 도구가 있거나 ** 매우 큰 모음이있는 경우입니다 ** 많은 프로젝트에서 필요로하는 라이브러리 유형 코드를 변경하지 마십시오. 그러나 이러한 조건이 있더라도 여전히 설득력이 필요합니다. 하지만 내가 말하자면, 상황이있을 수 있습니다 그 외부 (나는 svn 1.6 파일 외장을 지원하는 1.6) 특히 가치가 발생하지 않을 수 있습니다 –
이 도움이 될지 모르겠지만 svncopy.pl를 사용하여 분기/태그를 사용하고 외부 참조를 적절한 저장소 버전 번호로 업데이트하지만 비정상적인 경우 - 경로에 공백이 없어야합니다. –
트렁크가 얼마나 안정적이라고 생각 하느냐에 따라 다릅니다.
그러나 개발자가 외부의 작업 복사본을 트렁크로 전환해도 괜찮습니다. 개발 지점 내 트렁크를 가리키는 것도 좋습니다. 프로젝트의 첫 번째 안정적인 릴리스 전에 트렁크를 가리킬 수도 있습니다.
내 개인적인 생각은 나에게 특별한 의미가 있으므로 트렁크를 매우 신중하게 다루는 것입니다. 그것은 프로젝트의 전체 역사입니다. 출시되는 모든 것은 정의에 따라 트렁크를 통과해야합니다. 트렁크를 변경에 대한 리비전을 기록하지 않고 변경할 수있는 경우 (트렁크 외부를 가리키면 효과적으로 일어나는 일입니다), 해당 리비전을 릴리스 할 때 제어권을 잃었고 해당 리비전을 프로젝트에 통합 할 때 .
트렁크에서 분기 할 때 특정 버전에 대한 모든 참조를 변경하는 것은 재판 일 수 있습니다. 허드슨은 태깅 지원으로 상황을 더 잘 보이게 할 수 있지만 그 외에는 거의 도움이되지 않습니다.
트렁크를 가리킬 경우 "untouchable library"문제가 발생할 수도 있습니다.
CI와 관련하여 최종 통합 프로젝트뿐만 아니라 모든 구성 요소에서 CI를 수행 할 이유가 없습니다. 최신 라이브러리에서 병합 할시기를 선택하면 통합 작업을 수행 할시기를 선택할 수 있습니다.
그러나 "귀하의 프로젝트는 오래된 라이브러리를 사용하고 최신 버전은 X입니다."라는 메커니즘이 있으면 좋을 것입니다. 지금은 불가능합니다.
또한 중첩 된 외부 객체가있는 경우 기본 라이브러리에서 기본 프로젝트에 도달 할 때까지 5 개의 참조 레이어를 통해 변경 사항을 푸는 것은 쉽지 않습니다.
감사합니다. 좋은 조언입니다. 질문 - 출시되는 모든 것이 트렁크를 통과한다면, 트렁크에 다시 병합되어 태그를 해제하기위한 변경 사항이 포함되어야합니다. 맞습니까? –
나는 개념적으로 흐름이 [선택 사항] dev 브랜치 -> 트렁크 -> 브랜치 브랜치에서 발생하는 것을 볼 수있다. 내가 릴리스 지점에서 트렁크에 coz 변경 사항을 분기를 직접 릴리스하지 않았을 병합하지 않습니다. 이제 실제로는 다른 방법으로 처리해야하며 병합 기록을 가짜로 만들어야합니다. 그러나 해당 워크 플로를 사용하면 다음 작업을 수행 할 수 있습니다. http://stackoverflow.com/questions/1082699/1082881#1082881 –
의미가 있습니다 - 트렁크가 다른 트렁크에 대한 외부 참조를 만들 수 있도록 허용되며 불안정한 환경이 될 수 있습니다. 어쨌든 이것이 적극적인 개발이고 컴파일 또는 단위 테스트에서 깨진 변경 사항이 나타나야합니다. –