소스 제어 시스템이 여전히 대부분 파일로 백업되는 이유는 무엇입니까?

더 많은 소스 제어 시스템이 여전히 버전 데이터를 저장하는 수단으로 파일을 사용하는 것 같습니다. Vault와 TFS는 Sql Server를 데이터 저장소로 사용하므로 데이터 일관성과 속도가 더 좋을 것이라고 생각합니다.

그래서 SVN, 왜 GIT, CVS 등이 여전히 실제 데이터베이스 소프트웨어를 사용하는 대신 파일 시스템을 기본 데이터베이스로 사용한다고 생각합니다 (SVN 서버가 정상적인 커밋 중에 손상 되었으므로이 질문을합니다). MSSQL, Oracle, Postgre 등)?

편집 : 내 질문을하는 또 다른 방법은 "VCS 개발자가 기존 시스템을 사용하는 대신 자체 구조적 데이터 스토리지 시스템을 굴리는 이유는 무엇입니까?"라고 생각합니다.

TL; DR : 데이터베이스 관리 시스템은 데이터베이스를 필요로하지 않기 때문에 거의 사용하지 않습니다.

질문 답변에 대한 질문으로 왜 그렇지 않습니까? 이 문맥에서 "실제"데이터베이스 시스템은 파일 시스템에 비해 어떤 이점이 있습니까?

수정본 제어는 대부분 작은 메타 데이터와 많은 텍스트 차이를 추적한다는 점을 고려하십시오. 텍스트는 데이터베이스에보다 효율적으로 저장되지 않으며 컨텐츠의 색인 가능성은 중요하지 않습니다.

Git (논쟁을 위해)이 백엔드로 BDB 또는 SQLite DB를 사용하여 데이터를 저장했다고 가정합니다. 그것에 대해 더 신뢰할만한 것은 무엇입니까? 간단한 파일을 손상시킬 수있는 것은 데이터베이스를 손상시킬 수 있습니다 (더 복잡한 인코딩을 사용하는 간단한 파일이기 때문에).

프로그래머가 필요하지 않으면 최적화하지 않는 패러다임에서 개정 제어 시스템이 충분히 빠르고 안정적으로 작동한다면 왜 더 복잡한 시스템을 사용하도록 전체 설계를 변경해야합니까?

SVN 및 CVS에 대한 경험을 바탕으로 많은 가정을하고있는 것 같습니다.

Git과 Mercurial은 기본적으로 SVN 및 CVS와 같습니다.

git과 CVS를 비교하는 것은 iPad와 Atari를 비교하는 것과 같습니다. CVS는 공룡들이 지구를 돌아 다닐 때 만들어졌습니다 . Subversion은 기본적으로 CVS의 개선 된 버전입니다. git 및 Mercurial과 같은 최신 버전 제어 시스템이 이와 같이 작동한다고 가정하면 의미가 거의 없습니다.

관계형 데이터베이스는 단일 목적 데이터베이스보다 효율적입니다.

왜? 관계형 데이터베이스는 실제로 복잡하며 단일 목적 데이터베이스만큼 효율적이지 않을 수 있습니다. 내 머리 꼭대기와 약간의 차이가 있습니다.

• 어쨌든 동시에 여러 커밋을 수행 할 수 없으므로 버전 제어 시스템은 복잡한 잠금이 필요하지 않습니다.
• 로컬 데이터베이스는 저장소의 전체 사본이므로 분산 버전 제어 시스템은 매우 공간 효율적이어야합니다.
• 버전 관리 시스템은 몇 가지 특정 방식 (작성자, 수정본 ID, 때로는 전체 텍스트 검색)으로 만 데이터를 조회하면됩니다. 저자 / 수정 ID 검색을 처리 할 수있는 자체 데이터베이스를 만드는 것은 쉽지 않으며 전체 텍스트 검색은 내가 시도한 관계형 데이터베이스에서 그리 빠르지 않습니다.
• 버전 관리 시스템은 여러 플랫폼에서 작동해야합니다. 따라서 MySQL 또는 PostgreSQL과 같은 서비스로 설치 및 실행해야하는 데이터베이스를 사용하기가 더 어려워집니다.
• 로컬 컴퓨터의 버전 제어 시스템은 커밋과 같은 작업을 수행 할 때만 실행하면됩니다. 커밋을 수행하려는 경우를 대비 하여 MySQL과 같은 서비스를 항상 실행 하는 것은 낭비입니다.
• 대부분의 경우 버전 제어 시스템은 히스토리를 삭제하지 않고 추가하기 만하면됩니다. 이는 서로 다른 최적화 및 무결성 보호 방법으로 이어질 수 있습니다.

관계형 데이터베이스가 더 안전합니다

또 왜? 데이터가 파일에 저장되기 때문에 git 및 Mercurial과 같은 버전 제어 시스템에는 원자 커밋 이 없지만 그렇게합니다. 관계형 데이터베이스 는 데이터베이스를 파일로 저장합니다. CVS 가 원자 커밋을 수행 하지 않는다는 점에서 주목할 만하지 만 관계형 데이터베이스를 사용하지 않기 때문에 암흑기 때문일 가능성이 큽니다.

데이터베이스에 데이터가 들어 오면 손상으로부터 데이터를 보호하는 문제도 있으며, 그 대답은 같습니다. 파일 시스템이 손상된 경우 사용중인 데이터베이스는 중요하지 않습니다. 파일 시스템이 손상되지 않은 경우 데이터베이스 엔진이 손상되었을 수 있습니다. 왜 버전 제어 데이터베이스가 관계형 데이터베이스보다 더 쉬운 지 알 수 없습니다.

모든 복제본에서 전체 저장소를 복원 할 수 있기 때문에 분산 버전 제어 시스템 (git 및 Mercurial과 같은)이 중앙 집중식 버전 제어보다 데이터베이스를 보호하는 것이 좋습니다. 따라서 모든 백업과 함께 중앙 서버가 자발적으로 타는 git init경우 새 서버에서 실행 한 다음 개발자의 머신git push 에서 복원하여 복원 할 수 있습니다 .

바퀴를 재발견하는 것은 나쁘다

당신은 그냥 있기 때문에 할 수 있는 저장 문제에 대한 관계형 데이터베이스를 사용하면 의미하지 않는다 해야한다 . 관계형 데이터베이스 대신 구성 파일을 사용하는 이유는 무엇입니까? 관계형 데이터베이스에 데이터를 저장할 수 있는데 왜 파일 시스템에 이미지를 저장합니까? 관계형 데이터베이스에 코드를 모두 저장할 수 있는데 왜 파일 시스템에 코드를 보관해야합니까?

"만약 당신이 가지고있는 망치라면 모든 것이 못처럼 보입니다."

오픈 소스 프로젝트 수 있다는 사실도 있습니다 여유 가 편리 할 때마다 상업적인 프로젝트를 수행하는 것이 당신이 자원 제약의 같은 종류를 가지고 있지 않기 때문에, 바퀴를 재발견 할 수는. 데이터베이스 작성 전문가 인 자원 봉사자가 있다면 왜 그것을 사용하지 않습니까?

개정 제어 시스템의 작성자가 자신이하는 일을 알 수있는 이유는 무엇입니까. 다른 VCS에 대해서는 말할 수 없지만 Linus Torvalds 가 파일 시스템을 이해하고 있다고 확신합니다 .

왜 일부 상용 버전 제어 시스템은 관계형 데이터베이스를 사용합니까?

아마도 다음과 같은 조합이 될 것입니다.

• 일부 개발자는 데이터베이스를 작성 하고 싶지 않습니다 .
• 상용 버전 제어 시스템 개발자는 시간과 리소스 제약이 있으므로 이미 원하는 것에 가까운 데이터베이스를 작성할 수 없습니다. 또한 개발자는 비용이 많이 들고 데이터베이스 개발자 (데이터베이스를 쓰는 사람과 마찬가지로)는 아마도 더 비쌉니다. 대부분의 사람들은 그런 경험이 없기 때문입니다.
• 상용 버전 제어 시스템 사용자는 이미 관계형 데이터베이스가 있기 때문에 관계형 데이터베이스를 설정하고 실행하는 오버 헤드에 대해 신경 쓰지 않을 것입니다.
• 상용 버전 제어 시스템 사용자는 개정 데이터를 백업하는 관계형 데이터베이스 를 원할 가능성이 높습니다 . 예를 들어 백업과 같이 프로세스와 더 잘 통합 될 수 있기 때문입니다.

실제로 svn저장소에 BDB를 사용하는 데 사용됩니다. 이것은 파손되기 쉽기 때문에 결국 제거되었습니다.

현재 DB (SQLite)를 사용하는 다른 VCS는 fossil입니다. 또한 버그 추적기를 통합합니다.

실제 이유는 VCS가 많은 파일로 작동한다는 것입니다. 파일 시스템은 또 다른 종류의 데이터베이스 (CLOB / BLOB 스토리지 효율성에 중점을 둔 계층 적)입니다. 파일 시스템이 이미 존재할 이유가 없기 때문에 일반 데이터베이스는 잘 처리하지 못합니다.

1. 파일 시스템 은 데이터베이스입니다. 물론 관계형 데이터베이스는 아니지만 대부분은 매우 효율적인 키 / 값 저장소입니다. 또한 액세스 패턴이 키-값 저장소 (예 : git 저장소 형식)에 적합하게 디자인 된 경우 데이터베이스를 사용하더라도 파일 시스템을 사용하는 것보다 큰 이점을 제공하지 못할 수 있습니다. (사실, 그것은 방해를받는 또 다른 추상화 계층 일뿐입니다.)

2. 많은 데이터베이스 기능은 추가 수하물입니다. 전문 검색? 전체 텍스트 검색이 소스 코드에 적합합니까? 아니면 다르게 토큰 화해야합니까? 또한 모든 버전에서 전체 파일을 저장해야합니다. 많은 버전 제어 시스템은 공간을 절약하기 위해 Subversion 및 Git 과 같은 공간을 절약하기 위해 동일한 파일 개정판 사이에 델타를 저장합니다 (적어도 팩 파일 사용시).

3. 크로스 플랫폼 요구 사항으로 인해 데이터베이스 사용이 더욱 어려워졌습니다.

   대부분의 버전 관리 도구는 여러 플랫폼에서 실행되도록 제작되었습니다. 중앙 집중식 버전 제어 도구의 경우 이는 서버 구성 요소에만 영향을 주지만 Unix 사용자는 Microsoft SQL Server를 설치할 수없고 Windows 사용자는 PostgreSQL 또는 MySQL을 설치하지 않을 수 있으므로 단일 데이터베이스 서버에 의존하는 것은 여전히 ​​어렵습니다. 파일 시스템은 가장 일반적인 분모입니다. 그러나 Windows 시스템에 서버를 설치해야하는 여러 도구가 있으므로 SourceGear Vault 및 Microsoft Team Foundation Server 와 같은 SQL Server가 필요합니다 .

   분산 버전 제어 시스템은 모든 사용자가 리포지토리의 복사본을 가져 오기 때문에 여전히 어려운 작업입니다. 즉, 모든 사용자는 저장소를 배치 할 데이터베이스가 필요합니다. 이것은 소프트웨어가 다음을 의미합니다.

   1. 특정 데이터베이스가 존재하는 플랫폼의 하위 세트로 제한
   2. 크로스 플랫폼 (예 : SQLite) 인 단일 데이터베이스 백엔드를 대상으로합니다.
   3. 플러그 가능한 스토리지 백엔드를 대상으로하여 원하는 모든 데이터베이스 (파일 시스템 포함)를 사용할 수 있습니다.

   따라서 대부분의 분산 버전 제어 시스템은 파일 시스템 만 사용하십시오. 주목할만한 예외는 SourceGear 's Veracity 이며, 이는 SQLite 데이터베이스 (로컬 리포지토리에 유용) 또는 SQL Server와 같은 관계형 데이터베이스 (서버에 유용 할 수 있음)에 저장할 수 있습니다. 클라우드 호스팅 제품 은 Amazon SimpleDB와 같은 비 관계형 스토리지 백엔드를 사용할 수 있습니다 그러나 나는 이것이 사실인지 모른다.

내가 많은 오퍼링에서 보았던 한, 파일이 작업에 "충분한"것처럼 보이며, VCSes 출력도 파일이라는 점을 고려하면 합리적인 것입니다.

svn / git / etc 인터페이스와 함께 RDBMS 백엔드를 제공하는 많은 회사가 있으므로 기본적으로 요구하는 것이 이미 존재합니다.

버전 제어 시스템의 기본 데이터 구조는 데이터베이스에 매우 잘 매핑되지 않는 DAG이기 때문입니다. 많은 데이터는 내용을 다룰 수 있으며 데이터베이스에도 매우 잘못 매핑됩니다.

데이터 무결성은 VCS의 유일한 관심사 일뿐만 아니라 데이터베이스가 그리 좋지 않은 버전 기록 무결성 과 관련이 있습니다 . 즉, 버전을 검색 할 때 버전에 현재 결함이 없는지 확인해야 할뿐만 아니라 전체 히스토리에서 아무것도 변경되지 않았는지 확인해야합니다.

VCS는 엔터프라이즈 제품 외에 소비자 제품이기도합니다. 사람들은 작은 일인 취미 프로젝트에 사용합니다. 데이터베이스 서버 설치 및 구성의 번거 로움을 추가하면 시장의 상당 부분을 소외시킬 것입니다. 집에 Vault 및 TFS 설치가 많이 보이지 않는 것 같습니다. 스프레드 시트와 워드 프로세서가 데이터베이스를 사용하지 않는 것과 같은 이유입니다.

또한 이것은 DVCS에 대한 더 많은 이유이지만 데이터베이스를 사용하지 않으면 이식성이 뛰어납니다. 데이터베이스 서버 프로세스를 구성하지 않고도 소스 트리를 썸 드라이브에 복사하여 모든 컴퓨터에서 재사용 할 수 있습니다.

커밋 중에 손상되는 한 VCS는 데이터베이스와 동일한 기술을 사용하여 동시 액세스를 방지하고 트랜잭션을 원자화하는 등의 작업 을 수행 합니다. 둘 다 손상은 매우 드물지만 발생 합니다. 모든 의도와 목적을 위해 VCS 데이터 저장소 는 데이터베이스입니다.

• 더 나은 재해 복구 (최악의 시나리오 : 예전처럼 눈으로 파싱합니다)

• VCS 시스템의 결함으로 인해 발생할 수있는 이러한 재난을 쉽게 추적하고 디버깅 할 수 있습니다.

• 종속성 수를 줄입니다. (해당 시스템 중 하나가 커널을 처리 하고 있고 다른 하나는 커널을 처리 하는 것을 잊지 마십시오 )

• 텍스트 편집기는 항상 사용 가능합니다. (MS SQL Server 라이센스 ...별로 많지 않음)

Fossil 은 뛰어난 분산 버전 제어 시스템 (DVCS)이며 일반 텍스트 파일이 아닌 저장을 위해 SQLite를 사용합니다.

나는 버그 추적, Wiki 및 실제로 배포 된 것을 정말로 좋아합니다. 실제로 오프라인에서 작업하고 버그를 수정할 수 있습니다.

화석은 Sqlite를 응용 프로그램 파일 형식으로 사용합니다. PgCon 의 기조 연설에서 Richard Hipp 박사는 sqlite를 응용 프로그램 파일 시스템으로 사용함으로써 얻을 수있는 이점이 무엇인지 설명하고 데이터베이스를 파일 시스템으로 사용하는 것의 이점에 대해 상당히 설득력있는 주장을합니다.

두 번째 주요 주제는 SQLite를 응용 프로그램 파일 형식으로보아야한다는 것입니다. 자체 파일 형식을 개발하거나 ZIP 형식의 XML을 사용하는 대신 사용할 수 있습니다. “SQLite는 PostgreSQL을 대체하지 않습니다. SQLite는 fopen ()”손톱을 대체합니다 (슬라이드 21). 마지막으로 Richard는 SQLite가 데이터 (충돌 안전, ACID) use-the-index.com을 관리한다는 사실에 많은 중점을 두었습니다.

이제 박사는 Hipp는 데이터베이스에 코드를 저장의 문제를 해결했다

• Fossil이 분산 NoSQL 데이터베이스 대신 SQLite를 기반으로하는 이유는 무엇입니까?

화석은 SQLite를 기반으로하지 않습니다. 현재 Fossil 구현에서는 SQLite를 분산 데이터베이스의 콘텐츠에 대한 로컬 저장소로 사용하고 빠르고 쉬운 프레젠테이션을 위해 사전 계산 된 분산 데이터베이스에 대한 메타 정보 캐시로 사용합니다. 그러나이 역할에서 SQLite를 사용하는 것은 구현 세부 사항이며 디자인의 기본이 아닙니다. 이후 버전의 Fossil은 SQLite를 없애고 SQLite 대신 파일 더미 또는 키 / 값 데이터베이스를 대체 할 수 있습니다. (실제로 SQLite가 현재 역할에서 놀랍도록 잘 작동하기 때문에 일어날 가능성은 거의 없지만 요점은 Fossil에서 SQLite를 생략하는 것이 이론적 인 가능성이라는 것입니다.)