SVN은 Git보다 어떤 기능을 수행합니까? [닫은]

프로그래머 도구에 대한 대부분의 논쟁은 개인의 선택 (사용자에 의한) 또는 디자인 강조 , 즉 특정 사용 사례에 따라 (도구 제작자에 의한) 디자인 최적화로 증류된다는 데는 의문의 여지가 없습니다 . 텍스트 편집기는 아마도 가장 눈에 띄는 예입니다. 직장에서 Windows로 작업하고 가정에서 Mac 으로 Haskell 에서 코드를 작성하는 코더 , 크로스 플랫폼 및 컴파일러 통합의 가치를 평가하므로 TextMate 보다 Emacs 를 선택하는 등

새로 도입 된 기술이 현존하는 옵션보다 실제로 우수하다는 사실은 흔하지 않습니다.

실제로 버전 제어 시스템 (VCS), 특히 중앙 집중식 VCS ( CVS 및 SVN )와 분산 형 VCS ( Git 및 Mercurial )의 경우입니까?

SVN을 약 5 년 동안 사용했으며 현재는 SVN을 사용하고 있습니다. 3 년 전, 나는 모든 개인 프로젝트를 위해 Git (및 GitHub)으로 전환했습니다.

Subversion에 대한 Git의 많은 장점을 생각할 수 있지만 (중앙 집중식 VCS를 통해 분산되는 이점에 대한 추상적 인 개념) 하나의 반대 예제는 생각할 수 없습니다. 일부 과제는 관련이 있으며 프로그래머에게는 일반적으로 발생합니다. Subversion이 Git보다 낫습니다.

내가 얻은 유일한 결론은 데이터가 없다는 것입니다 .Git이 더 좋다는 것 등은 아닙니다.

내 생각 엔 그러한 반례가 존재하기 때문에이 질문입니다.

Subversion은 중앙 저장소입니다

많은 사람들이 속도와 여러 복사본의 명백한 이점을 위해 분산 리포지토리를 원하지만 중앙 리포지토리가 더 바람직한 상황이 있습니다. 예를 들어, 누군가가 액세스하기를 원하지 않는 중요한 코드가 있다면 Git 아래에두기를 원하지 않을 것입니다. 많은 기업들이 코드를 중앙 집중식으로 유지하기를 원하며 모든 (심각한) 정부 프로젝트는 중앙 저장소에 있습니다.

전복은 기존의 지혜입니다

이것은 많은 사람들 (특히 관리자와 상사)이 버전을 번호 매기기위한 일반적인 방법을 가지고 있으며 개발 과정을 시간이 지남에 따라 "단일 라인"으로 보는 것이 두뇌에 하드 코딩되었음을 의미합니다. 공격은 없지만 Git의 자유는 삼키기가 쉽지 않습니다. Git 서적의 첫 번째 장에서는 모든 기존의 이상을 마음에서 비우고 새로 시작해야합니다.

Subversion은 한 가지 방법으로 만 수행하며 다른 방법은 없습니다.

SVN은 버전 관리 시스템입니다. 그것은 일을하는 한 가지 방법이 있으며 모두가 같은 방식으로합니다. 기간. 따라서 SVN에서 다른 중앙 VCS로 또는 다른 중앙 VCS로 쉽게 전환 할 수 있습니다. Git은 순수한 VCS가 아니며 파일 시스템이며 다양한 상황에서 리포지토리를 설정하는 방법에 대한 많은 토폴로지를 가지고 있으며 표준은 없습니다. 하나를 선택하기가 어렵습니다.

다른 장점은 다음과 같습니다.

• SVN은 빈 디렉토리를 지원합니다
• SVN의 Windows 지원 향상
• SVN은 하위 트리를 체크 아웃 / 복제 할 수 있습니다
• SVN은 svn lock병합하기 어려운 파일에 유용한 독점적 액세스 제어 를 지원 합니다
• SVN은 이진 파일과 큰 파일을 더 쉽게 지원하며 이전 버전을 어디에서나 복사 할 필요가 없습니다.
• 커밋을 추가하면 풀 / 푸시가 없으며 로컬 변경 사항이 항상 암시 적으로 기반하므로 단계가 훨씬 적습니다 svn update.

Git에 비해 Subversion의 이점 중 하나는 Subversion이 하위 트리 만 체크 아웃 할 수 있다는 것입니다. Git을 사용하면 전체 저장소가 하나의 단위이므로 모든 것을 얻거나 전혀 얻을 수 없습니다. 모듈 식 코드를 사용하면 Git 하위 모듈에 비해 상당히 좋습니다. (Git 서브 모듈도 그 자리에 있지만.)

작은 장점 : Subversion은 빈 디렉토리를 추적 할 수 있습니다. Git은 파일 내용을 추적하므로 파일이없는 디렉토리는 표시되지 않습니다.

세 가지 생각할 수 있습니다. 첫째, 특히 개발자가 아닌 사람에게는 이해하기가 훨씬 쉽습니다. 개념적으로 DCVS 옵션 보다 훨씬 간단 합니다. 둘째는 성숙도, 특히 Windows의 TortoiseSVN 입니다. TortoiseHg 는 빨리 따라 잡고 있습니다. 셋째, 짐승의 본질 (나무의 모든 레벨에서 항목을 확인할 수있는 파일 시스템의 이미지)은 수십 개의 다양한 구성 파일을 다양한 버전으로 버전 화하는 것과 같은 일부 시나리오에서 매우 유용 할 수 있습니다. 수십 개의 저장소가없는 서버

우리가 모든 개발을 Mercurial로 옮기지 않았다는 것은 아닙니다.

• SVN 리포지토리는 관리자 및 관리자의 관점에서보다 관리가 용이합니다 ( ACL + 인증 방법 + 핫 카피 + 미러 + 덤프)
• SVN * 후크는 구현 및 지원이 더 쉽습니다.
• svn:external 서브 모듈보다 더 강력한 성능과 유연성
• 파일 시스템 기반 저장소 트리는 논리적으로 분리 된 단일 저장소보다 사용하기 쉽습니다.
• SVN보다가 다른 클라이언트 도구를
• SVN은 타사의 유용한 웹 프론트 엔드를 가지고 있습니다.
• SVN은 당신의 두뇌를 파괴하지 않습니다

나는 이것을 다른 사람의 대답에 대한 의견으로 썼지 만 그 자체로 대답 할 가치가 있다고 생각합니다.

우리 회사가 SVN에 대해 신중하게 선택한 구성은 컨텐츠를 편집하기 위해 파일 레벨 잠금이 필요하며 절대 병합을 사용하지 않습니다. 결과적으로 여러 개발자가 잠금을 놓고 경쟁하여 심각한 병목 현상이 발생할 수 있으며 병합 충돌이 발생할 가능성은 없습니다.

SVN은 Git보다 하향식 관리 제어를 확실히 수행합니다. 내 skunkworks에서 Git으로의 마이그레이션 (권한이 아닌 용서 요청)에서 우리 모두가 노예가되는 소프트웨어 적용 중앙 마스터 제어 서버가 없다는 생각으로 관리자를 여러 번 두려워했습니다.

내 이유 :

• 성숙도-서버 및 도구 (예 : TortoiseSVN)
• 단순성-단계가 적을수록 커밋은 커밋입니다. Git 및 Mercurial과 같은 DVCS는 커밋을 수행 한 다음 푸시합니다.
• 이진 처리-SVN은 Git / Hg보다 이진 실행 파일과 이미지를 더 잘 처리합니다. 빌드 관련 도구를 소스 제어로 확인하고 싶기 때문에 .NET 프로젝트에 특히 유용합니다.
• 번호 매기기-SVN에는 숫자 만 사용하여 읽을 수있는 커밋 번호 매기기 체계가 있으므로 수정 번호를 쉽게 추적 할 수 있습니다. 힘내와 Hg는 이것을 아주 다르게합니다.

좋은 정보를 찾아 주셔서 감사합니다. 그러나 이런 종류의 질문은 "Git이 많은 승리를 거둔다고 생각합니다. 답변.

나는 작은 팀을 위해 Git을 너무 많이 찾았습니다. 지리적으로 분산되어있는 대규모 분산 팀 또는 팀 그룹에게는 좋을 것 같습니다. 나는 Git의 이점을 크게 이해하지만 내 의견으로는 소스 컨트롤이 밤에 나를 방해하는 것이 아닙니다.

나는 사슴 사냥꾼이며 나와 친구들이 외출 할 때 탄약과 첨단 장비로 강모 된 치아로 무장합니다. 나는 소총 하나, 총알 7 개, 벅 나이프로 나타납니다. 만약 내가 7 라운드 이상을 필요로한다면 나는 무언가 잘못하고있는 것입니다.

내가하려고하는 요점은 중소 규모 프로젝트에서 작업하는 소규모 팀이고 이미 SVN에 익숙한 경우 사용하는 것입니다. CVS 또는 (shudder) SourceSafe 보다 확실히 좋으며 리포지토리를 설정하는 데 5 분 이상 걸리지 않습니다. 힘내 때때로 과잉 수 있습니다.

이것은 모두 상대적이며, maple_shaft가 말했듯이, 하나가 당신에게 효과적이라면 변경하지 마십시오!

그러나 정말로 무언가를 원한다면 디자이너, 웹 프로그래머 등에 게 더 좋을 것입니다. 이미지와 이진 파일 을 조금 더 잘 처리합니다.

사용성. 실제로 Subversion의 장점은 아니지만 TortoiseSVN 의 장점입니다 . TortoiseGit 이 있지만 TortoiseSVN과 일치하는 데는 아직 먼 길이 있습니다.

Git이 SVN보다 나은지 물어 보면 GitHub에 답장을 보냅니다 . 써드 파티 도구가 그렇게 큰 차이를 만드는 방법은 재미 있습니다.

이 경우 분기 및 병합 할 필요가 없습니다 (와 SVN을 TortoiseSVN을 Windows에서) 이해하고 사용하기가 매우 쉽습니다. Git은 분기 / 병합을 쉽게하기 위해 간단한 경우에 지나치게 복잡합니다.

(많은 소규모 프로젝트가 제대로 관리된다면 분기 할 필요가 없습니다. Git은 복잡한 경우를 목표로하기 때문에 대부분의 Git 문서에서는 분기 및 병합과 같은 복잡한 작업을 수행해야한다고 가정합니다.)

할아버지는 Windows XP 컴퓨터에서 SVN을 사용할 수 있지만 Git을 사용하는 데 문제가있었습니다. 어쩌면 이것은 TortoiseGit 보다 TortoiseSVN 의 성취 일 수도 있지만, Git이 본질적으로 더 강력하고 더 복잡하다는 사실과 관련이 있다고 생각합니다.

할아버지가 늦게 프로그래밍을하지 않았기 때문에 이제 할아버지에게는 문제가되지 않습니다. 그러나 저는 한때 그래픽 아티스트가 소스 컨트롤을 사용하는 팀에있었습니다.

그리고 그들은 단순히 도구가 작동하기를 기대하는 사람들입니다 (그렇지만 나도 실패 할 경우 실제로 작동 할 수있는 현실적인 기회가 있습니다). 사실, 그들이 DVCS 와 잘 어울리게 하기 위해 많은 노력을 기울 였을 것 입니다. 또한 팀에 프로그래머가 두 명뿐이므로 SVN 만 사용하는 것이 좋습니다.

직장에서 개발자를 SVN에서 DVCS 로 전환 할 수 없었습니다 .

• 부분 체크 아웃 (예 : 프로젝트 트리에서 깊이가 다른 세 개의 폴더 만)
• 파일 잠금 (이진 형식 보고서)

• 'svn commit'을 수행 할 때의 보안 감각. 커밋은 서버로 이동하기 때문에 변경 사항이 커밋 된 후 지워질 수있는 스크류 업이 없습니다. git에서 커밋은 로컬이므로 눌릴 때까지 길 잃은 'rm -rf'가 끝났습니다.
• 커밋이 인증됩니다. 기본적으로 git에서는 누군가로 커밋한다고 말할 수 있습니다.
• 일상적인 사용법을 배우는 명령이 적습니다. 'svn checkout', 'svn up'및 'svn commit'은 당신을 꽤 멀리 이끌어 줄 것입니다.
• 공유 체크 아웃이 훨씬 잘 작동합니다. 커밋 할 때 사용자 이름 / 암호를 묻는 메시지가 표시되면 특정 명령 줄 인수를 전달해야한다는 것을 기억하지 않아도됩니다. 때로는 직장에서 일부 프로젝트의 공유 svn 체크 아웃이있는 공유 컴퓨터가 있습니다. 누군가가 "이 기계에서 이것을 볼 수 있습니까?"라고 말하면 가능하며, 사용자의 변경없이 자신의 변경 사항을 커밋 할 수 있습니다.
• 리포지토리 레이아웃. 우산 프로젝트와 하위 프로젝트를 보유하고 언제 체크 아웃 할 것인지 선택할 수 있습니다.
• 개정 번호는 증분 정수입니다.
• 중앙 저장소 워크 플로우를 위해 설계되었습니다.

다른 사람들이 꽤 좋은 답변을 게시했지만 권한은 어떻습니까? Subversion over SSH를 사용하면 서버에서 SVN에 대해 별도의 계정을 만들 수 있습니다. 저장소마다 다른 개발자에게 다른 액세스 권한을 부여 할 수 있습니다. GIT가 그렇게 할 수 있습니까? 나는 gitolite가 있다고 생각하지만, 그것은 나에게 융통성이나 강건한 것처럼 보이지 않으며 실제로 그것을 사용하는 사람을 알지 못합니다.

속도. 큰 자식 저장소를 복제하는 데 때로는 10 분 또는 15 분이 걸리지 만 비슷한 크기의 서브 버전 저장소는 체크 아웃하는 데 몇 분이 걸립니다.

나는 이것을 주석이 아닌 응답으로 게시합니다.

DVCS가 현재 추세에 있다는 것을 인정하지만 그 이유를 말하려고 노력할 것입니다.

DVCS는 많은 사람들이 말했듯이 "이것은 우리가 처음부터 작업해야했던 방식"이기 때문에 더 좋습니다. 사실, SVN에서 사용했던 것을 DVCS로 할 수 있으므로 SVN을 쓸모 없게 만듭니다.

그러나 모든 소프트웨어 프로젝트가 얻는 것만 큼 좋은 것은 아닙니다.

• 장기 프로젝트는 DVCS의 이점을 많이받습니다. 오버 헤드가 적고 관리 기능이 훨씬 뛰어나며 (분기 등) Google 코드 및 github와 같은 호스트가 크게 지원하기 때문입니다.

• 이러한 프로젝트는 유일한 프로젝트가 아니며 외부 또는 인터넷의 도움없이 회사에서 개발중인 다른 종류의 프로젝트가 있습니다. 모든 것이 내부적으로 이루어지며 종종 단기적으로 이루어집니다. 좋은 예 : 비디오 게임. 코드는 빠르게 발전합니다.

후자의 경우 개발자는 실제로 DVCS가 제공 할 수있는 브랜칭 또는 정교한 기능이 필요하지 않으며 소스 코드와 자산을 공유하기 만하면됩니다. 마감일이 있기 때문에 그들이 만든 코드는 재사용되지 않을 것입니다. 몇 가지 이유로 인해 DVCS가 아닌 SVN에 의존합니다.

• 개발자는 회사에 속한 기계를 가지고 있으며 이는 빠르게 변경 될 수 있습니다. 저장소를 구성하면 시간이 손실됩니다.
• 그 사람들이 자신의 머신을 가지고 있지 않다면, 프로젝트의 동일한 소스 코드 / 부분에서 작업 할 가능성이 줄어 듭니다. 중앙 집중식 데이터를위한 하나입니다.
• 네트워크 속도와 큰 돈으로 모든 SVN을 처리하는 중앙 서버를 사용할 수 있습니다. 나쁜 습관이지만 백업 등이 있습니다.
• SVN은 잘못된 방법 일지라도 사용하기 가 더 간단 합니다. 중복없이 피어에서 파일을 동기화하는 것은 간단한 문제가 아니며, 항상 완벽하게 원한다면 "올바른 방법으로 수행"할 수 없습니다.

게임 산업 기계와 SVN이 어떻게 시간을 절약하는지 생각해보십시오. 게임은 반복적 인 프로그래밍과 적응 코드에 관한 것이기 때문에 사람들은 그 프로젝트에서 훨씬 더 많은 의사 소통을합니다. 프로그래머는 고용되고, 코드를 작성하고, 컴파일하고, 약간 테스트하고, 커밋하고, 완료하며, 게임 테스터는 나머지를 처리합니다.

DVCS는 인터넷과 매우 복잡한 프로젝트를 위해 만들어졌습니다. SVN은 소규모 단기 프로젝트 팀입니다. SVN에서 많은 것을 배울 필요는 없습니다. 거의 바보 같은 FTP입니다.

Subversion과 Git은 모두 개발 및 협업에 대한 특정 (매우 다른) 접근 방식을 권장합니다. 일부 조직은 Git에서 더 많은 것을 얻고 다른 조직은 조직과 문화에 따라 Subversion에서 더 많은 것을 얻습니다.

Git과 Mercurial은 유능한 전문 프로그래머로 구성된 분산되고 느슨하게 구성된 팀에 탁월합니다. 이 인기있는 DVCS 도구는 소규모 저장소를 권장하며 개발자는 비교적 비교적 안정적인 인터페이스를 갖춘 게시 된 라이브러리를 통해 재사용합니다.

반면 Subversion은 개발자 간의 커뮤니케이션이 향상되고 일상적인 개발 활동을보다 조직적으로 제어 할 수있는보다 중앙 집중식으로 밀접하게 연결된 관리 구조를 장려합니다. 보다 간결하게 구성된이 팀 내에서 개발자 간의 재사용은 (상대적으로) 불안정한 인터페이스가있는 게시되지 않은 라이브러리를 통해 발생하는 경향이 있습니다. TortoiseSVN은 또한 Subversion이 전문 프로그래머가 아닌 구성원 (예 : 시스템 엔지니어, 알고리즘 엔지니어 또는 기타 주제 분야 전문가)과 함께 여러 분야의 팀을 지원할 수 있도록합니다.

팀이 분산되어 있거나 집이나 다른 여러 국제 사이트에서 일하는 회원과 또는 직접 대면 통신을하지 않고 혼자서 침묵하는 일을 선호하는 경우 Git 또는 Mercurial과 같은 DVCS가 좋습니다. 문화적 적합.

반면에 팀이 단일 사이트에 있고 개발에 대한 "팀"접근 방식을 사용하고 공중에서 "버즈"를 사용하여 많은 대면 커뮤니케이션을하는 경우 SVN은 특히 학제 간 팀이 많은 경우 더 나은 문화적 적합성.

물론 Git과 Hg (강력하고 유연함)를 원하는대로 구성 할 수는 있지만 확실히 더 많은 작업을 수행 할 수 있으며 특히 팀원에게 특히 사용하기가 더 어렵습니다. 당연히 어떤 형태의 버전 제어도 사용하려는 경향이 없습니다.

마지막으로, Svn (CI 및 테스트 중심 접근 방식) 하에서 "핫"라이브러리 개발을 사용하여 기능을 공유하면보다 분산되고 느슨하게 결합 된 팀으로는 달성하기 어려운 조정 된 개발 속도가 허용됩니다.

아래는 여전히 SVN을 유지하는 두 가지 이유입니다.

1. 학습 곡선. SVN은 Git보다 설정 (서버 또는 클라이언트도), 유용성 및 명령보다 쉽습니다.
2. Subversion Edge , VisualSVN , uberSVN 등과 같은 더 나은 서버 패키지

현재 버전 관리에는 두 가지 주요 트렌드가 있습니다. 배포 및 통합 .

Git은 분산화에 뛰어납니다.

SVN에는 통합 된 많은 도구가 있습니다. 수정 사항을 체크인 할 때 체크인 주석에 버그 번호를 언급하고이를 자동으로 "테스트 중"상태로 설정하고 할당 된 테스터에게 경고를 보내도록 SVN 서버를 설정하는 것이 일반적입니다. 보세요 그런 다음 릴리스에 태그를 지정하고이 릴리스에서 수정 된 모든 버그 목록을 얻을 수 있습니다.

SVN으로이를 수행하는 도구는 성숙하여 매일 사용됩니다.

Subversion에서는 커밋이 완료된 후 로그 메시지 ( "커밋 메시지"라고도 함)를 편집 할 수 있습니다. 대부분의 실제적인 용도로는 git을 포함한 분산 시스템에서 설계 상 불가능합니다. 물론 git에서는 "git commit --amend"을 수행 할 수 있지만 커밋을 다른 곳으로 푸시 한 후에는 도움이되지 않습니다. SVN에서는 로그 메시지를 편집 할 때 모든 사람이 공유하는 중앙 저장소에서 로그 메시지를 작성하므로 모든 사람이 개정의 식별자를 변경하지 않고도 편집 할 수 있습니다.

사실 이후의 로그 메시지 편집은 종종 매우 유용합니다. 로그 메시지에서 실수 나 누락을 수정하는 것 외에도 향후 커밋 을 참조하기 위해 로그 메시지를 업데이트하는 것과 같은 작업을 수행 할 수 있습니다 (예 : 버그를 수정하거나 현재 개정에서 도입 된 작업을 완료하는 개정) .

그런데 정보를 잃어 버릴 위험이 없습니다. pre-revprop-change 및 post-revprop-change 후크는 실제로 우려되는 경우 이전 메시지의 기록을 저장하거나 로그 메시지 diff (이는 더 일반적입니다)와 함께 전자 메일을 보낼 수 있으므로 감사 추적.