여러 프로젝트의 Subversion 개정 번호
https://stackoverflow.com/questions/15674
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
여러 프로젝트에서 소스 제어를 위해 Subversion(svn)을 사용할 때 모든 프로젝트 디렉터리에서 개정 번호가 증가하는 것을 확인했습니다.내 svn 레이아웃을 설명하려면(가상의 프로젝트 이름 사용):
/NinjaProg/branches
/tags
/trunk
/StealthApp/branches
/tags
/trunk
/SnailApp/branches
/tags
/trunk
Ninja 프로그램의 트렁크에 커밋을 수행할 때 버전 7로 업데이트되었다는 메시지를 받았다고 가정해 보겠습니다.다음 날 Stealth 애플리케이션에 약간의 변경을 가해 개정판 8로 돌아온다고 가정해 보겠습니다.
질문은 이것입니다: 하나의 Subversion 서버로 여러 프로젝트를 유지 관리할 때 모든 프로젝트에서 관련 없는 프로젝트의 개정 번호를 늘리는 것이 일반적으로 허용되는 관행입니까? 아니면 내가 잘못하고 있어서 각 프로젝트마다 개별 저장소를 만들어야 합니까?아니면 완전히 다른 것입니까?
편집하다: 두 접근 방식 모두에 이유가 있다는 것이 분명해졌기 때문에 답변 표시를 미뤘으며, 이 질문이 먼저 나왔음에도 불구하고 궁극적으로 동일한 질문을 던지는 다른 질문을 지적하고 싶습니다.
해결책
온라인에서 무료로 제공되는 Subversion을 사용한 버전 관리에서 이것이 논의되었다는 언급이 없다는 사실에 놀랐습니다. 여기.
얼마 전에 이 문제에 대해 읽었는데 이는 개인 선택의 문제인 것 같습니다. 해당 주제에 대한 좋은 블로그 게시물이 있습니다. 여기.편집하다: 블로그가 다운된 것 같으니 (여기에 보관된 버전), 여기에 Mark Phippard가 이 주제에 대해 말한 내용 중 일부가 있습니다.
이는 단일 저장소 접근 방식의 장점 중 일부입니다.
- 단순화된 관리.배포할 후크 세트 1개.백업할 저장소가 하나입니다.등.
- 분기/태그 유연성.하나의 저장소에 코드가 모두 포함되어 있어 여러 프로젝트와 관련된 분기나 태그를 더 쉽게 생성할 수 있습니다.
- 코드를 쉽게 이동하세요.아마도 한 프로젝트의 코드 섹션을 가져와 다른 프로젝트에서 사용하거나 여러 프로젝트의 라이브러리로 전환하고 싶을 수도 있습니다.동일한 저장소 내에서 코드를 이동하고 프로세스에서 코드 기록을 유지하는 것은 쉽습니다.
다음은 단일 저장소 접근 방식의 몇 가지 단점과 다중 저장소 접근 방식의 장점입니다.
- 크기.하나의 큰 저장소보다 여러 개의 작은 저장소를 처리하는 것이 더 쉬울 수 있습니다.예를 들어, 프로젝트를 폐기하는 경우 저장소를 미디어에 보관하고 디스크에서 제거하여 저장소를 확보할 수 있습니다.새로운 Subversion 기능을 활용하는 등 어떤 이유로 저장소를 덤프/로드해야 할 수도 있습니다.저장소가 작을수록 수행하기가 더 쉽고 영향도 적습니다.결국 모든 리포지토리에 이 작업을 수행하려는 경우에도 한 번에 모두 수행해야 할 긴급한 필요가 없다는 가정하에 한 번에 하나씩 수행하는 것이 영향을 덜 받습니다.
- 글로벌 개정 번호.이것이 문제가 되어서는 안 되지만 일부 사람들은 이를 문제로 인식하고 저장소에서 개정 번호가 올라가는 것을 보고 싶지 않으며 비활성 프로젝트의 개정 기록에 큰 간격이 있는 것을 좋아하지 않습니다.
- 액세스 제어.Subversion의 인증 메커니즘을 사용하면 필요에 따라 저장소의 일부에 대한 액세스를 제한할 수 있지만 저장소 수준에서 이를 수행하는 것이 여전히 더 쉽습니다.선택된 소수의 개인만 액세스해야 하는 프로젝트가 있는 경우 해당 프로젝트에 대한 단일 저장소를 사용하는 것이 더 쉽습니다.
- 관리 유연성.저장소가 여러 개인 경우 저장소/프로젝트의 요구 사항에 따라 다양한 후크 스크립트를 구현하는 것이 더 쉽습니다.균일한 후크 스크립트를 원한다면 단일 저장소가 더 나을 수 있지만 각 프로젝트가 자체 커밋 이메일 스타일을 원하는 경우 해당 프로젝트를 별도의 저장소에 두는 것이 더 쉽습니다.
실제로 생각해 보면 여러 프로젝트 저장소의 개정 번호가 높아질 것이지만 부족하지는 않을 것입니다.하위 디렉터리의 기록을 볼 수 있고 프로젝트와 관련된 모든 개정 번호를 빠르게 볼 수 있다는 점을 명심하세요.
다른 팁
각 프로젝트마다 별도의 저장소를 만드는 것이 좋습니다.당신이 말하는 시나리오를 피하는 것 외에는 아무것도 없습니다.
버전 제어, 특히 Subversion을 사용하면 저장소의 일부를 다른 작업 복사본으로 쉽게 체크아웃한 다음 해당 저장소에 다시 커밋할 수 있습니다.이를 통해 상당한 유연성을 제공하면서 명확하게 분리되고 구별되는 상태를 유지할 수 있습니다.SVN에 좀 더 익숙해지면(당신이 처음인 것으로 가정합니다.) 후크 사용을 시작할 수 있으며 설정 시 어디가 어려울 수 있는지 알 수 있습니다.권한이 중요한 경우 단일 저장소가 필요 이상으로 어려울 수 있습니다.
또한 각 저장소를 설정하는 데 많은 시간이 걸릴 것으로 우려되는 경우 Apache 구성 파일에 대한 SVNParentPath 변수를 살펴보세요.(다시 한번 말하지만, Apache를 사용하고 있다고 가정합니다.)
이는 전복이 작동하는 방식 때문입니다.각 개정판은 실제로 해당 개정 번호로 식별되는 저장소의 스냅샷입니다.모든 프로젝트가 저장소를 공유한다면 이는 불가피합니다.그러나 내 경험에 따르면 일반적으로 전혀 관련이 없는 프로젝트에 대해 별도의 저장소를 설정하게 됩니다.따라서 짧은 대답은 '아니요'입니다. 이는 Subversion과 관련된 일반적인 질문이지만 저장소 정보를 저장하는 방법을 생각하면 의미가 있습니다.
개정 번호는 실제로 특정 버전에 대한 식별자여야 합니다.프로젝트의 순차적인지 여부는 중요하지 않습니다.즉, 이상적이지 않다는 것을 이해할 수 있습니다.
내가 만난 대부분의 프로젝트는 단일 저장소에 설정되었으며 개정 ID는 이런 방식으로 작동합니다.이 동작을 변경하는 SVN 구성 옵션을 모르고 IMHO, 여러 리포지토리를 유지 관리하는 것이 불필요한 오버헤드처럼 보입니다.
귀하의 예와 거의 동일하게 모든 것을 포함하는 하나의 저장소가 있습니다.
나는 이것에 아무런 문제가 없다고 볼 수 있습니다. 개정 번호에 대한 유일한 요구 사항은 그것이라는 것입니다
- 고유한
- 원자
- 지난번 체크인 때보다 더 컸어요
내가 생각하는 한 각 커밋마다 1씩 증가하든지 50씩 증가하든 상관없습니다.
@grom:
그런 다음 새 프로젝트를 시작할 때마다 다음을 실행합니다.
svnadmin create /var/www/svn/myproject
개발자가 1~2명뿐이라면 이 작업이 제대로 작동하는 것을 볼 수 있지만 새 프로젝트를 만드는 사람들이 /var/www 아래에 디렉터리를 만들 수 있는 SVN 서버에 대한 셸 액세스 권한이 없으면 어떻게 되나요?
프로젝트별로 별도의 저장소를 사용하는 것이 좋습니다.내 Apache conf.d 디렉토리에는 다음을 포함하는 subversion.conf가 있습니다.
<Location /svn>
DAV svn
SVNParentPath /var/www/svn
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /var/www/svn/password
Require valid-user
</Location>
그런 다음 새 프로젝트를 시작할 때마다 다음을 실행합니다.
svnadmin create /var/www/svn/myproject
흠, 제가 일하는 곳에서는 모든 프로젝트가 동일한 저장소에 있습니다.나는 그것들을 분리하는 것의 이점을 정말로 보지 못합니다. 새로운 저장소 생성, 사람들에게 액세스 권한 부여 등의 추가 작업이 많이 발생하지 않습니까?프로젝트가 전혀 관련이 없고 예를 들어 저장소에 액세스해야 하는 외부 고객이 있는 경우 별도의 저장소가 의미가 있다고 생각합니다.
내 직장에는 두 개의 저장소가 있습니다.하나는 공개 읽기 액세스 권한이고 다른 하나는 기타 모든 권한입니다.모든 작업에 하나만 사용하겠지만 공개/비공개 프로젝트에는 서로 다른 액세스 권한이 필요합니다.
즉, 저는 개인적으로 업데이트할 때마다 개정 번호가 증가하는 문제를 보지 못했습니다.개정 번호는 소수와 짝수를 건너뛰어도 여전히 예상되는 작업을 수행할 수 있습니다.특정 개정판을 쉽게 얻을 수 있습니다.
다른 프로젝트에 따라 개정 번호를 변경하는 것이 귀찮다면 프로젝트를 별도의 저장소에 넣으십시오.이것이 개정 번호를 독립적으로 만드는 유일한 방법입니다.
나에게 다른 저장소를 사용하는 가장 큰 이유는 사용자에게 별도의 액세스 제어를 제공하거나 다른 후크 스크립트를 사용하는 것입니다.
어쩌면 "프로젝트"당 하나의 저장소를 만드는 것이 아니라 "솔루션"당 하나의 저장소를 만드는 것이 가장 좋습니다(Visual Studio 용어 사용).서로 다른 폴더에 여러 개의 "프로젝트"가 있지만 서로 관련되어 있는 경우 동일한 저장소에 넣으세요.
당신이 정말로 생각할 때, 여러 프로젝트 저장소의 개정 번호는 높아질 것이지만, 당신은 다 떨어지지 않을 것입니다.하위 디렉토리에서 기록을보고 프로젝트와 관련된 모든 개정 번호를 신속하게 볼 수 있습니다.
실제로 Microsoft 코드를 작성하고 버전 문자열의 일부로 svn 개정 번호를 사용하는 경우에는 부족할 수 있습니다.버전 문자열의 일부가 65535보다 크면 Microsoft 컴파일러에서 오류가 발생합니다....우리의 경우 개정판 68876에 대규모 저장소가 있는데 이 벽에 부딪혔습니다.
프로젝트당 하나의 저장소.
CC.NET에 대한 Steven Murawski의 의견은 흥미롭습니다.여러 소스 제어 저장소를 지정해야 하는 경우 어떻게 작동하는지 듣고 싶습니다.
@다니엘 폰:SVN 문서에서는 저장소당 하나의 프로젝트를 권장하므로 이는 확실히 제작자가 의도한 방식입니다.하나의 서버(apache 또는 svnserve)가 여러 리포지토리를 유지하도록 할 수 있으므로 오버헤드가 너무 많은 문제에 부딪힌 적이 없습니다.와 함께 VisualSVN 서버, 아파치 서버를 설치하고 여러 저장소를 구성하는 것은 간단합니다.
SVN 문서가 실제로 저장소당 하나의 프로젝트를 권장하는지 잘 모르겠습니다.대부분 그들은 각 경로의 장점과 단점에 대해 이야기합니다.나는 세 가지 다른 저장소를 사용하는데, 하나는 모두 관련된 7~8개의 프로젝트에 대해 하나의 개정판에서 빌드하는 것만으로도 모든 프로젝트의 호환 가능한 복사본을 보낼 수 있다는 점이 매우 좋습니다. 각각의 개정 번호 참조).두 번째 저장소에는 관련 프로젝트 및 문서의 또 다른 그룹이 있고, 세 번째 저장소에는 훨씬 작은 그룹이 있습니다.이를 통해 관련 프로젝트를 단일 개정 번호로 관리할 수 있지만 관련되지 않은 프로젝트는 저장소에 영향을 미치지 않는다는 사실을 활용할 수 있습니다.
개정 번호에는 의미상 사용이 없습니다.유일한 것은 순서대로 정렬되어 있다는 것입니다.프로젝트를 덤프하고 다른 저장소로 가져오면 버전이 새로운 개정 번호를 얻을 수 있습니다.그래서 절대 릴리스 또는 이와 유사한 항목을 표시하려면 개정 번호를 사용하십시오.릴리스(관련 개정판의 사본)에 대한 태그를 만듭니다.
이전 회사에서도 같은 문제가 있었습니다. 그들은 하나의 저장소에서 50개 정도의 프로젝트를 실행하곤 했는데 svn 업데이트를 할 때 다른 사람들이 욕할 것이기 때문에 같은 프로젝트에서 작업하는 것은 악몽이었습니다....ㅋㅋㅋ...
제가 배운 한 가지는 항상 가장 잘 작동한다는 것입니다. One project One Repo....절대 후회하지 않을 것입니다.
