Tại sao các hệ thống kiểm soát nguồn vẫn chủ yếu được hỗ trợ với các tệp?

Có vẻ như nhiều hệ thống kiểm soát nguồn vẫn sử dụng các tệp làm phương tiện lưu trữ dữ liệu phiên bản. Vault và TFS sử dụng Sql Server làm kho lưu trữ dữ liệu của họ, điều mà tôi nghĩ sẽ tốt hơn cho tính nhất quán dữ liệu cũng như tốc độ.

Vậy tại sao SVN, tôi tin rằng GIT, CVS, v.v. vẫn sử dụng hệ thống tệp như là một cơ sở dữ liệu, (tôi hỏi câu hỏi này vì chúng tôi đã có máy chủ SVN của chúng tôi tự hỏng trong một cam kết bình thường) thay vì sử dụng phần mềm cơ sở dữ liệu thực tế ( MSSQL, Oracle, Postgre, v.v.)?

EDIT: Tôi nghĩ một cách khác để đặt câu hỏi của tôi là "tại sao các nhà phát triển VCS cuộn hệ thống lưu trữ dữ liệu có cấu trúc của riêng họ thay vì sử dụng một hệ thống hiện có?"

TL; DR: Rất ít hệ thống kiểm soát phiên bản sử dụng cơ sở dữ liệu vì không cần thiết.

Là một câu hỏi cho một câu trả lời câu hỏi, tại sao họ sẽ không? Những lợi ích nào mà hệ thống cơ sở dữ liệu "thực" mang lại cho một hệ thống tệp trong ngữ cảnh này?

Hãy xem xét rằng kiểm soát sửa đổi chủ yếu là theo dõi một siêu dữ liệu nhỏ và rất nhiều khác biệt văn bản. Văn bản không được lưu trữ trong cơ sở dữ liệu hiệu quả hơn và khả năng lập chỉ mục của nội dung sẽ không phải là một yếu tố.

Giả sử rằng Git (vì lợi ích của đối số) đã sử dụng BDB hoặc SQLite DB cho back-end của nó để lưu trữ dữ liệu. Điều gì sẽ đáng tin cậy hơn về điều đó? Bất cứ điều gì có thể làm hỏng các tệp đơn giản cũng có thể làm hỏng cơ sở dữ liệu (vì đó cũng là một tệp đơn giản với mã hóa phức tạp hơn).

Từ mô hình lập trình viên không tối ưu hóa trừ khi cần thiết, nếu hệ thống kiểm soát sửa đổi đủ nhanh và hoạt động đủ tin cậy, tại sao phải thay đổi toàn bộ thiết kế để sử dụng một hệ thống phức tạp hơn?

Bạn dường như đang đưa ra rất nhiều giả định, có thể dựa trên kinh nghiệm của bạn với SVN và CVS.

Git và Mercurial về cơ bản giống như SVN và CVS

So sánh git và CVS giống như so sánh iPad và Atari. CVS được tạo lại khi những con khủng long lang thang trên Trái đất . Subversion về cơ bản là một phiên bản cải tiến của CVS. Giả sử rằng các hệ thống kiểm soát phiên bản hiện đại như git và Mercurial hoạt động như chúng có rất ít ý nghĩa.

Cơ sở dữ liệu quan hệ hiệu quả hơn cơ sở dữ liệu đơn mục đích

Tại sao? Cơ sở dữ liệu quan hệ thực sự phức tạp và có thể không hiệu quả như cơ sở dữ liệu đơn mục đích. Một số khác biệt ngoài đỉnh đầu của tôi:

• Các hệ thống kiểm soát phiên bản không cần khóa phức tạp, vì dù sao bạn cũng không thể thực hiện nhiều lần xác nhận.
• Các hệ thống kiểm soát phiên bản phân tán cần phải cực kỳ hiệu quả về không gian, vì cơ sở dữ liệu cục bộ là bản sao đầy đủ của repo.
• Các hệ thống kiểm soát phiên bản chỉ cần tra cứu dữ liệu theo một vài cách cụ thể (theo tác giả, theo ID sửa đổi, đôi khi là tìm kiếm toàn văn). Tạo cơ sở dữ liệu của riêng bạn có thể xử lý các tìm kiếm ID tác giả / sửa đổi là chuyện nhỏ và tìm kiếm toàn văn bản không nhanh lắm trong bất kỳ cơ sở dữ liệu quan hệ nào tôi đã thử.
• Hệ thống kiểm soát phiên bản cần phải hoạt động trên nhiều nền tảng. Điều này làm cho việc sử dụng một cơ sở dữ liệu cần được cài đặt và chạy như một dịch vụ (như MySQL hoặc PostgreQuery) khó khăn hơn.
• Hệ thống kiểm soát phiên bản trên máy cục bộ của bạn chỉ cần chạy khi bạn đang làm gì đó (như cam kết). Rời khỏi một dịch vụ như MySQL chạy mọi lúc chỉ trong trường hợp bạn muốn thực hiện một cam kết là lãng phí.
• Đối với hầu hết các phần, các hệ thống kiểm soát phiên bản không bao giờ muốn xóa lịch sử, chỉ cần thêm vào nó. Điều đó có thể dẫn đến các tối ưu hóa khác nhau và các phương pháp bảo vệ tính toàn vẹn khác nhau.

Cơ sở dữ liệu quan hệ an toàn hơn

Một lần nữa, tại sao? Bạn dường như cho rằng vì dữ liệu được lưu trữ trong các tệp, các hệ thống kiểm soát phiên bản như git và Mercurial không có các cam kết nguyên tử , nhưng chúng có. Cơ sở dữ liệu quan hệ cũng lưu trữ cơ sở dữ liệu của họ dưới dạng tệp. Điều đáng chú ý ở đây là CVS không thực hiện các cam kết nguyên tử, nhưng đó có thể là vì nó từ thời kỳ đen tối, không phải vì họ không sử dụng cơ sở dữ liệu quan hệ.

Ngoài ra còn có vấn đề bảo vệ dữ liệu khỏi tham nhũng một khi nó có trong cơ sở dữ liệu, và một lần nữa câu trả lời là như vậy. Nếu hệ thống tập tin bị hỏng, thì bạn không sử dụng cơ sở dữ liệu nào. Nếu hệ thống tập tin không bị hỏng, thì công cụ cơ sở dữ liệu của bạn có thể bị hỏng. Tôi không thấy lý do tại sao cơ sở dữ liệu kiểm soát phiên bản sẽ dễ bị điều này hơn cơ sở dữ liệu quan hệ.

Tôi cho rằng các hệ thống kiểm soát phiên bản phân tán (như git và Mercurial) sẽ tốt hơn cho việc bảo vệ cơ sở dữ liệu của bạn so với kiểm soát phiên bản tập trung, vì bạn có thể khôi phục toàn bộ repo từ bất kỳ bản sao nào. Vì vậy, nếu máy chủ trung tâm của bạn tự động đốt cháy, cùng với tất cả các bản sao lưu của bạn, bạn có thể khôi phục nó bằng cách chạy git inittrên máy chủ mới, sau đó git pushtừ bất kỳ máy nào của nhà phát triển .

Phát minh lại bánh xe là xấu

Chỉ vì bạn có thể sử dụng cơ sở dữ liệu quan hệ cho bất kỳ vấn đề lưu trữ nào không có nghĩa là bạn nên làm . Tại sao bạn sử dụng tệp cấu hình thay vì cơ sở dữ liệu quan hệ? Tại sao lưu trữ hình ảnh trên hệ thống tập tin khi bạn có thể lưu trữ dữ liệu trong cơ sở dữ liệu quan hệ? Tại sao giữ mã của bạn trên hệ thống tệp khi bạn có thể lưu trữ tất cả trong cơ sở dữ liệu quan hệ?

"Nếu tất cả những gì bạn có là một cái búa, mọi thứ trông giống như một cái đinh."

Ngoài ra còn có một thực tế là các dự án nguồn mở có thể đủ khả năng để phát minh lại bánh xe bất cứ khi nào thuận tiện, vì bạn không có các loại ràng buộc tài nguyên giống như các dự án thương mại. Nếu bạn có một tình nguyện viên là một chuyên gia viết cơ sở dữ liệu, thì tại sao không sử dụng chúng?

Về lý do tại sao chúng tôi sẽ tin tưởng các tác giả của các hệ thống kiểm soát sửa đổi để biết họ đang làm gì .. Tôi không thể nói cho các VCS khác, nhưng tôi khá tin tưởng rằng Linus Torvalds hiểu các hệ thống tệp .

Tại sao một số hệ thống kiểm soát phiên bản thương mại sử dụng cơ sở dữ liệu quan hệ sau đó?

Rất có thể là một số kết hợp sau đây:

• Một số nhà phát triển không muốn viết cơ sở dữ liệu.
• Các nhà phát triển hệ thống kiểm soát phiên bản thương mại có những hạn chế về thời gian và tài nguyên, vì vậy họ không đủ khả năng để viết cơ sở dữ liệu khi họ đã có thứ gì đó gần với những gì họ muốn. Ngoài ra, các nhà phát triển rất tốn kém và các nhà phát triển cơ sở dữ liệu (như, những người viết cơ sở dữ liệu) có thể đắt hơn, vì hầu hết mọi người không có loại kinh nghiệm đó.
• Người dùng hệ thống kiểm soát phiên bản thương mại ít quan tâm đến chi phí thiết lập và chạy cơ sở dữ liệu quan hệ, vì họ đã có sẵn.
• Người dùng hệ thống kiểm soát phiên bản thương mại có nhiều khả năng muốn có cơ sở dữ liệu quan hệ sao lưu dữ liệu sửa đổi của họ, vì điều này có thể tích hợp với các quy trình của họ tốt hơn (ví dụ như sao lưu).

Thực tế svnđược sử dụng để sử dụng BDB cho các kho lưu trữ. Điều này cuối cùng đã được loại bỏ bởi vì nó dễ bị phá vỡ.

Một VCS khác hiện đang sử dụng DB (SQLite) là fossil. Nó cũng tích hợp một trình theo dõi lỗi.

Tôi đoán lý do thực sự là các VCSes hoạt động với rất nhiều tệp. Hệ thống tập tin chỉ là một loại cơ sở dữ liệu khác (phân cấp, tập trung vào hiệu quả lưu trữ CLOB / BLOB). Cơ sở dữ liệu thông thường không xử lý tốt điều đó vì không có lý do nào - các hệ thống tập tin đã tồn tại.

1. Một hệ thống tập tin là một cơ sở dữ liệu. Tất nhiên không phải là cơ sở dữ liệu quan hệ, nhưng hầu hết là các kho lưu trữ khóa / giá trị rất hiệu quả. Và nếu các mẫu truy cập của bạn được thiết kế tốt cho kho lưu trữ khóa-giá trị (ví dụ: định dạng kho git), thì việc sử dụng cơ sở dữ liệu có thể không mang lại lợi thế đáng kể so với sử dụng hệ thống tệp. (Trên thực tế, đó chỉ là một lớp trừu tượng khác để cản trở.)

2. Rất nhiều tính năng cơ sở dữ liệu chỉ là hành lý bổ sung. Tìm kiếm toàn văn? Liệu tìm kiếm toàn văn có ý nghĩa cho mã nguồn? Hay bạn cần token hóa nó khác nhau? Điều này cũng yêu cầu bạn lưu trữ các tệp đầy đủ ở mỗi lần sửa đổi, điều này không phổ biến. Nhiều hệ thống kiểm soát phiên bản lưu trữ đồng bằng giữa các lần sửa đổi của cùng một tệp để tiết kiệm dung lượng, ví dụ Subversion và Git (ít nhất là khi sử dụng tệp gói.)

3. Các yêu cầu đa nền tảng làm cho việc sử dụng một cơ sở dữ liệu trở nên khó khăn hơn.

   Hầu hết các công cụ kiểm soát phiên bản được xây dựng để chạy trên nhiều nền tảng. Đối với các công cụ kiểm soát phiên bản tập trung, điều này chỉ ảnh hưởng đến thành phần máy chủ, nhưng vẫn khó dựa vào một máy chủ cơ sở dữ liệu vì người dùng Unix không thể cài đặt Microsoft SQL Server và người dùng Windows có thể không muốn cài đặt PostgreQuery hoặc MySQL. Hệ thống tập tin là mẫu số ít phổ biến nhất. Tuy nhiên, có một số công cụ mà máy chủ phải được cài đặt trên máy Windows và do đó yêu cầu SQL Server, ví dụ SourceGear Vault và Microsoft Team Foundation Server .

   Các hệ thống kiểm soát phiên bản phân tán làm cho điều này trở nên khó khăn hơn vì mọi người dùng đều có một bản sao của kho lưu trữ. Điều này có nghĩa là mọi người dùng đều cần một cơ sở dữ liệu để đưa kho lưu trữ vào. Điều này ngụ ý rằng phần mềm:

   1. Được giới hạn trong một tập hợp con của các nền tảng có cơ sở dữ liệu cụ thể
   2. Nhắm mục tiêu một phụ trợ cơ sở dữ liệu duy nhất là đa nền tảng (ví dụ: SQLite).
   3. Nhắm mục tiêu một phụ trợ lưu trữ có thể cắm, để người ta có thể sử dụng bất kỳ cơ sở dữ liệu nào họ muốn (có thể bao gồm cả hệ thống tệp).

   Hầu hết các hệ thống kiểm soát phiên bản phân tán, do đó, chỉ cần sử dụng hệ thống tập tin. Một ngoại lệ đáng chú ý là Veracity của SourceGear , có thể lưu trữ trong cơ sở dữ liệu SQLite (hữu ích cho kho lưu trữ cục bộ) hoặc cơ sở dữ liệu quan hệ như SQL Server (có thể hữu ích cho máy chủ.) Việc cung cấp lưu trữ đám mây của họ có thể sử dụng phụ trợ lưu trữ không liên quan như Amazon SimpleDB , nhưng tôi không biết điều này là đúng.

Theo như tôi đã thấy trong nhiều dịch vụ, có vẻ như các tệp "đủ tốt" cho công việc, một điều hợp lý, có tính đến việc vào cuối ngày đầu ra của VCSes cũng là các tệp.

Có nhiều công ty cung cấp mặt sau RDBMS với giao diện svn / git / etc, vì vậy những gì bạn đang yêu cầu về cơ bản đã tồn tại.

Tôi muốn nói rằng đó là vì cấu trúc dữ liệu chính của hệ thống kiểm soát phiên bản là DAG, ánh xạ tới cơ sở dữ liệu rất kém. Rất nhiều dữ liệu cũng có thể truy cập nội dung, nó cũng ánh xạ tới cơ sở dữ liệu rất kém.

Tính toàn vẹn dữ liệu không phải là mối quan tâm duy nhất của VCS, họ cũng quan tâm đến tính toàn vẹn lịch sử phiên bản , cơ sở dữ liệu không tốt lắm. Nói cách khác, khi bạn truy xuất một phiên bản, bạn không chỉ cần đảm bảo rằng phiên bản đó không có sai sót hiện tại, mà còn không có gì trong toàn bộ lịch sử của nó đã bị thay đổi một cách lén lút.

VCS cũng là một sản phẩm tiêu dùng ngoài một sản phẩm doanh nghiệp. Mọi người sử dụng chúng trong các dự án sở thích nhỏ, một người đàn ông. Nếu bạn thêm rắc rối khi cài đặt và định cấu hình máy chủ cơ sở dữ liệu, bạn sẽ xa lánh phần lớn thị trường đó. Tôi đoán bạn không thấy nhiều cài đặt Vault và TFS ở nhà. Đó là cùng một lý do bảng tính và trình xử lý văn bản không sử dụng cơ sở dữ liệu.

Ngoài ra, đây là một lý do cho DVCS, nhưng việc không sử dụng cơ sở dữ liệu làm cho nó cực kỳ di động. Tôi có thể sao chép cây nguồn của mình vào ổ USB và sử dụng lại trên bất kỳ máy nào mà không phải cấu hình quy trình máy chủ cơ sở dữ liệu.

Theo như tham nhũng trong quá trình cam kết, VCS sử dụng các kỹ thuật chính xác giống như cơ sở dữ liệu để ngăn chặn truy cập đồng thời, thực hiện giao dịch nguyên tử, v.v ... Tham nhũng ở cả hai đều rất hiếm, nhưng chúng vẫn xảy ra . Đối với tất cả ý định và mục đích, kho dữ liệu VCS là một cơ sở dữ liệu.

• Phục hồi thảm họa tốt hơn (trường hợp xấu nhất: chúng ta sẽ phân tích bằng mắt, như thời xưa)

• Việc theo dõi và gỡ lỗi những thảm họa như vậy, có thể do lỗi trong hệ thống VCS, dễ dàng hơn.

• Giảm số lượng phụ thuộc. (chúng ta không quên một trong những hệ thống là xử lý các hạt nhân, và người kia đã được yêu cầu)

• Một trình soạn thảo văn bản luôn có sẵn. (Giấy phép MS SQL Server ... không quá nhiều)

Fossil là một Hệ thống kiểm soát phiên bản phân tán (DVCS) tuyệt vời và sử dụng SQLite để lưu trữ, không có tệp văn bản thuần túy.

Tôi thực sự thích nó đã được tích hợp: theo dõi lỗi, Wiki và nó thực sự được phân phối. Tôi có nghĩa là bạn thực sự có thể làm việc ngoại tuyến và sửa lỗi.

Fossil sử dụng Sqlite như định dạng tệp ứng dụng. Trong bài phát biểu tại PGCon, Tiến sĩ Richard Hipp giải thích những lợi thế của việc sử dụng sqlite làm Hệ thống tệp ứng dụng và đưa ra một lập luận khá thuyết phục về lợi ích của việc sử dụng cơ sở dữ liệu làm hệ thống tệp.

Chủ đề chính thứ hai là SQLite nên được xem như là một định dạng tệp ứng dụng Thay thế cho việc phát minh các định dạng tệp của riêng mình hoặc sử dụng các XML được ZIP. Câu lệnh SQL SQLite không phải là sự thay thế cho PostgreSQL. SQLite là sự thay thế cho móng tay fopen () mà (slide 21). Cuối cùng, Richard rất chú trọng đến thực tế rằng SQLite chăm sóc dữ liệu của bạn (sự cố an toàn, ACID) sử dụng- the-index.com

Bây giờ Tiến sĩ Hipp đã giải quyết các mối quan tâm về việc lưu mã trên cơ sở dữ liệu

• Tại sao Fossil dựa trên SQLite thay vì cơ sở dữ liệu NoQuery phân tán?

Hóa thạch không dựa trên SQLite. Việc triển khai Fossil hiện tại sử dụng SQLite làm kho lưu trữ cục bộ cho nội dung của cơ sở dữ liệu phân tán và làm bộ đệm cho thông tin meta về cơ sở dữ liệu phân tán được tính toán trước để trình bày nhanh chóng và dễ dàng. Nhưng việc sử dụng SQLite trong vai trò này là một chi tiết triển khai và không phải là cơ bản cho thiết kế. Một số phiên bản tương lai của Fossil có thể loại bỏ SQLite và thay thế một tệp tệp hoặc cơ sở dữ liệu khóa / giá trị thay cho SQLite. (Trên thực tế, điều đó rất khó xảy ra vì SQLite hoạt động rất tốt trong vai trò hiện tại của nó, nhưng vấn đề là bỏ qua SQLite khỏi Fossil là một khả năng lý thuyết.)