Mengapa sistem kontrol sumber sebagian besar masih didukung dengan file?

22

Tampaknya lebih banyak sistem kontrol sumber masih menggunakan file sebagai cara menyimpan data versi. Vault dan TFS menggunakan Sql Server sebagai penyimpan data mereka, yang saya pikir akan lebih baik untuk konsistensi data serta kecepatan.

Jadi mengapa SVN, saya percaya GIT, CVS, dll masih menggunakan sistem file sebagai dasarnya sebuah database, (Saya mengajukan pertanyaan ini karena server SVN kami hanya merusak dirinya sendiri selama komit normal) daripada menggunakan perangkat lunak database aktual ( MSSQL, Oracle, Postgre, dll)?

EDIT: Saya pikir cara lain untuk mengajukan pertanyaan saya adalah "mengapa pengembang VCS menggulung sistem penyimpanan data terstruktur mereka sendiri daripada menggunakan yang ada?"

version-control Andy
sumber
29
Menurut Anda apa yang sebagian besar database gunakan sebagai dukungan dasar mereka? Sebagian besar menggunakan file (beberapa menggunakan akses langsung ke hard disk, namun). Anda dapat memiliki semua fitur database dengan menggunakan "file saja".
Joachim Sauer
2
@ JoachimSauer Fair point, meskipun tentu saja Anda harus membuat database sendiri. Yang konyol jika rangkaian fitur yang Anda inginkan dekat dengan yang ada solusi dan tidak memiliki alasan yang sangat baik untuk tidak menggunakan salah satu dari itu.
1
@ JoachimSauer Ya, saya menyadari itu, tetapi sistem DBM memiliki cara untuk memastikan bahwa tidak ada yang tidak konsisten masuk ke dalam database. Kecuali repositori berbasis file ini menggunakan sesuatu seperti Transactional NTSF, masih ada kemungkinan korup. Dan saya mempercayai database nyata lebih dari yang saya lakukan pada sekelompok pengembang yang pada dasarnya menciptakan kembali roda, karena saya pikir kita bisa sepakat bahwa sistem kontrol sumber memerlukan integritas data.
Andy
2
@delnan Dukungan transaksional dan konsistensi internal. Kami sekarang memulihkan repositori SVN kami dari tape b / c server SVN tidak menulis dengan benar untuk semua file yang seharusnya. Juga mencari volume data yang sangat besar. Maksud saya adalah, mengapa mencoba menemukan kembali roda.
Andy
7
Setiap sistem operasi utama dilengkapi dengan sistem file bawaan. Semua sistem file ini memiliki fungsi dasar yang sama (file, folder, ketekunan yang sama). Pada dasarnya, basis data adalah satu ketergantungan ekstra yang harus diinstal oleh pengguna akhir dan terus diperbarui. Kontrol sumber bukan bisnis utama kebanyakan orang (kecuali Anda adalah sourceforge atau github). VC sering diinstal pada server melalui baris perintah oleh anggota tim terbaru. Kemudahan pemasangan dan pengaturan penting.
GlenPeterson

Jawaban:

23

TL; DR: Beberapa sistem kontrol versi menggunakan database karena itu tidak perlu.

Sebagai pertanyaan untuk jawaban pertanyaan, mengapa tidak? Apa manfaat yang ditawarkan sistem database "nyata" di atas sistem file dalam konteks ini?

Pertimbangkan bahwa kontrol revisi sebagian besar melacak metadata kecil dan banyak perbedaan teks. Teks tidak disimpan dalam database lebih efisien, dan indeksabilitas konten tidak akan menjadi faktor.

Mari kita berasumsi bahwa Git (demi argumen) menggunakan BDB atau SQLite DB untuk back-end untuk menyimpan data. Apa yang lebih bisa diandalkan tentang itu? Apa pun yang dapat merusak file sederhana juga dapat merusak database (karena itu juga file sederhana dengan pengkodean yang lebih kompleks).

Dari paradigma programmer tidak mengoptimalkan kecuali jika diperlukan, jika sistem kontrol revisi cukup cepat dan bekerja cukup andal, mengapa mengubah seluruh desain untuk menggunakan sistem yang lebih kompleks?

mikebabcock
sumber
2
TLDR? Jawaban Anda dua kali lebih panjang dan pertanyaannya sangat singkat!
Brad
25
@Brad Tiga kata yang mengikuti TL;DRadalah versi singkat dari jawaban, bukan pernyataan bahwa pertanyaannya terlalu panjang dan dia tidak membacanya sebelum menjawab.
6
@Andy Mercurial juga memiliki "grep in history", dan git kemungkinan juga memilikinya. Ini juga cepat kilat. Adapun hal-hal yang diserahkan kepada ahli: Orang-orang yang mengembangkan VCS adalah ahli.
3
Hanya ingin menambahkan bahwa saya melihat maksud Anda; jika VCS menulis data yang buruk, tidak masalah jika menulis data itu ke file atau database. Sisi sebaliknya adalah bahwa repo berbasis file mungkin menulis ke lebih dari satu file pada satu waktu dan biasanya tidak ada dukungan transaksional untuk itu jadi jika satu file menulis tetapi gagal, VCS Anda sekarang rusak, vs tabel mutiple menulis dalam database transaksi akan dilakukan untuk gagal sebagai satu unit. Saya merasa seolah-olah sekelompok pengembang perangkat lunak basis data pengembang memiliki pengalaman lebih dengan ini daripada orang-orang yang menulis SVN ... tapi mungkin saya salah.
Andy
6
Pilihan Anda git "demi argumen" adalah poin penting di sini: git memiliki model yang sangat baik untuk menulis objeknya, tetapi banyak alat tidak. Dengan git, jika komputer dimatikan di tengah-tengah komit, Anda akan menulis beberapa objek ke sistem file dan mereka hanya akan terjangkau. Dengan VCS lain, Anda mungkin telah menambahkan perubahan ke setengah file (dan kebingungan terjadi.) Anda bisa berpendapat bahwa alat kontrol versi lainnya dirancang dengan buruk (dan Anda akan benar), tetapi ketika Anda menulis VCS, itu adalah jauh lebih mudah untuk hanya menggunakan transaksi SQL dan membiarkannya melakukan hal yang benar.
Edward Thomson
25

Anda tampaknya membuat banyak asumsi, mungkin berdasarkan pengalaman Anda dengan SVN dan CVS.

Git dan Mercurial pada dasarnya seperti SVN dan CVS

Membandingkan git dan CVS seperti membandingkan iPad dan Atari. CVS diciptakan kembali ketika dinoaurs menjelajahi Bumi . Subversi pada dasarnya adalah versi perbaikan CVS. Dengan asumsi bahwa sistem kontrol versi modern seperti git dan pekerjaan Mercurial seperti mereka sangat tidak masuk akal.

Database relasional lebih efisien daripada database tujuan tunggal

Mengapa? Basis data relasional sangat rumit, dan mungkin tidak seefisien basis data satu tujuan. Beberapa perbedaan dari kepala saya:

  • Sistem kontrol versi tidak perlu penguncian yang rumit, karena Anda tidak dapat melakukan banyak komit sekaligus.
  • Sistem kontrol versi terdistribusi harus sangat efisien ruang, karena database lokal adalah salinan lengkap dari repo.
  • Sistem kontrol versi hanya perlu mencari data dalam beberapa cara tertentu (oleh penulis, dengan revisi ID, terkadang pencarian teks lengkap). Membuat database Anda sendiri yang dapat menangani pencarian ID penulis / revisi itu sepele dan pencarian teks lengkap tidak terlalu cepat dalam database relasional yang saya coba.
  • Sistem kontrol versi perlu bekerja pada banyak platform. Ini membuatnya lebih sulit untuk menggunakan database yang perlu diinstal dan dijalankan sebagai layanan (seperti MySQL atau PostgreSQL).
  • Sistem kontrol versi pada mesin lokal Anda hanya perlu dijalankan ketika Anda melakukan sesuatu (seperti komit). Membiarkan layanan seperti MySQL berjalan sepanjang waktu untuk berjaga-jaga jika Anda ingin melakukan komit adalah sia-sia.
  • Untuk sebagian besar, sistem kontrol versi tidak pernah ingin menghapus riwayat, cukup tambahkan saja. Itu dapat mengarah pada berbagai optimisasi, dan berbagai metode melindungi integritas.

Database relasional lebih aman

Lagi-lagi kenapa? Anda tampaknya berasumsi bahwa karena data disimpan dalam file, sistem kontrol versi seperti git dan Mercurial tidak memiliki komitmen atom , tetapi mereka melakukannya. Database relasional juga menyimpan database mereka sebagai file. Penting dicatat di sini bahwa CVS tidak melakukan komitmen atom, tetapi itu kemungkinan karena itu berasal dari zaman kegelapan, bukan karena mereka tidak menggunakan basis data relasional.

Ada juga masalah melindungi data dari korupsi begitu ada dalam database, dan sekali lagi jawabannya sama. Jika sistem file rusak, maka tidak masalah database mana yang Anda gunakan. Jika sistem file tidak rusak, maka mesin database Anda mungkin rusak. Saya tidak melihat mengapa database kontrol versi akan lebih rentan terhadap ini daripada database relasional.

Saya berpendapat bahwa sistem kontrol versi terdistribusi (seperti git dan Mercurial) lebih baik untuk melindungi database Anda daripada kontrol versi terpusat, karena Anda dapat mengembalikan seluruh repo dari klon mana pun. Jadi, jika server pusat Anda terbakar secara spontan, bersama dengan semua cadangan Anda, Anda dapat memulihkannya dengan menjalankannya git initdi server baru, lalu git pushdari mesin pengembang mana pun .

Menemukan kembali roda itu buruk

Hanya karena Anda dapat menggunakan database relasional untuk masalah penyimpanan apa pun, bukan berarti Anda harus melakukannya . Mengapa Anda menggunakan file konfigurasi alih-alih database relasional? Mengapa menyimpan gambar pada sistem file ketika Anda bisa menyimpan data dalam database relasional? Mengapa menyimpan kode Anda di sistem file ketika Anda bisa menyimpan semuanya dalam database relasional?

"Jika yang kamu miliki adalah palu, semuanya terlihat seperti paku."

Ada juga fakta bahwa proyek-proyek sumber terbuka mampu menemukan kembali roda kapan pun nyaman, karena Anda tidak memiliki jenis kendala sumber daya yang sama dengan proyek-proyek komersial. Jika Anda memiliki sukarelawan yang ahli dalam menulis basis data, mengapa tidak menggunakannya?

Adapun mengapa kami akan mempercayai para penulis sistem kontrol revisi untuk mengetahui apa yang mereka lakukan .. Saya tidak dapat berbicara untuk VCS lain, tetapi saya cukup yakin bahwa Linus Torvalds memahami sistem file .

Mengapa beberapa sistem kontrol versi komersial menggunakan database relasional?

Kemungkinan kombinasi dari yang berikut ini:

  • Beberapa pengembang tidak ingin menulis basis data.
  • Pengembang sistem kontrol versi komersial memiliki keterbatasan waktu dan sumber daya, sehingga mereka tidak mampu menulis database ketika mereka memiliki sesuatu yang mendekati apa yang mereka inginkan. Juga, pengembang itu mahal, dan pengembang basis data (seperti pada, orang yang menulis database) mungkin lebih mahal, karena kebanyakan orang tidak memiliki pengalaman semacam itu.
  • Pengguna sistem kontrol versi komersial cenderung tidak peduli tentang overhead pengaturan dan menjalankan database relasional, karena mereka sudah memilikinya.
  • Pengguna sistem kontrol versi komersial lebih cenderung menginginkan database relasional mendukung data revisi mereka, karena ini dapat diintegrasikan dengan proses mereka lebih baik (seperti backup misalnya).
Pasang kembali Monica
sumber
1
Satu hal: Komitmen SVN bersifat atomik. Faktanya, ini adalah titik penjualan utama (atau paling tidak, ketika mereka harus meyakinkan pengguna CSV untuk beralih).
1
@delnan - Perhatikan bahwa ada perbedaan besar antara atomisitas teoretis yang Anda dapatkan dengan svndirektori berbeda di direktori kerja Anda yang bisa berada pada svnrevisi berbeda dan atomisitas lebar repositori sejati yang Anda dapatkan dengan gitatau hg.
Mark Booth
2
@Andy Dan poin saya adalah bahwa Anda dapat menangani skenario yang sama persis tanpa database relasional penuh. Jika dua orang melakukan pada waktu yang sama, server dapat melakukan satu demi satu. Itu bukan fitur yang rumit untuk diterapkan. Jika Anda ingin melakukannya dengan pengguna lokal, cukup buat file kunci. Saat Anda memulai komit, dapatkan kunci pada file. Saat Anda mengakhiri komit, lepaskan kunci. Jika Anda ingin mengizinkan komit ke beberapa cabang sekaligus, gunakan file kunci untuk setiap cabang. Tentu, SQLite akan melakukan ini untuk saya, tetapi itu tidak perlu .
Pasang kembali Monica
1
Demikian pula, menerapkan jurnal dasar juga tidak rumit. (1) Tulis komit baru ke file. (2) Salin file indeks yang lama. (3) Tulis file indeks baru. (4) Hapus salinan file indeks lama. Jika Anda gagal pada langkah 1, 2 atau 4, Anda hanya perlu membersihkan file baru yang Anda buat. Jika Anda gagal pada langkah 3, Anda hanya perlu menyalin kembali file indeks yang lama. Seseorang yang memahami sistem file lebih baik mungkin dapat membuat versi yang jauh lebih efisien dari ini, tetapi Anda selalu dapat referensi kode sumber SQLite jika Anda perlu (itu adalah domain publik).
Reinstate Monica
1
@ BrendanLong Poin bagus. Hargai diskusi ini. Untuk lebih jelasnya, saya pikir ada kelebihan dan kekurangan untuk kedua jenis toko dukungan, saya tidak percaya hanya ada satu jawaban yang benar. Namun saya agak terkejut tampaknya hanya ada tiga (empat jika Anda menghitung Vault dan Vercity secara terpisah) yang menggunakan SQL dan sebagian besar tidak, itu saja.
Andy
18

Sebenarnya svndigunakan untuk menggunakan BDB untuk repositori. Ini akhirnya dihilangkan karena rentan terhadap kerusakan.

VCS lain yang saat ini menggunakan DB (SQLite) adalah fossil. Ini juga mengintegrasikan pelacak bug.

Dugaan saya pada alasan sebenarnya adalah bahwa VCSes bekerja dengan banyak file. Filesystem hanyalah jenis database lain (hierarkis, fokus pada efisiensi penyimpanan CLOB / BLOB). Basis data normal tidak menangani dengan baik karena tidak ada alasan untuk - sistem file sudah ada.

Mike Larsen
sumber
1
BDB tidak akan secara tepat dianggap andal - seperti SQLite, ini merupakan basis data dalam proses. Yang mengatakan, saya pikir keandalan Oracle / MSSQL / MySQL / Postgres, tergantung pada bagaimana Anda mengkonfigurasinya, tidak jauh berbeda dari sistem file. Masalah utama adalah bahwa RDBMS tidak dibangun untuk struktur hierarkis & grafik yang biasa digunakan VCSes. Dan dalam hal ini, sistem file baru saja menang.
Mike Larsen
3
@Andy: Fosil diciptakan oleh pencipta SQLite. Tidak terlalu mengejutkan :-)
Jörg W Mittag
1
@ Andy: aku akan percaya SQLite jauh lebih dari Oracle atau MSSQL. Tidak heran bahwa itu adalah database SQL yang paling banyak digunakan di luar sana, dengan margin yang sangat besar. Juga yang diangkut ke arsitektur yang paling berbeda, masing-masing dengan tantangannya sendiri, membuat kode bersama ini sangat tahan peluru.
Javier
1
@ Javier Saya tidak akan mempercayai Sqlite sebanyak MSSQL atau Oracle; seperti kata Mike, bagian dalam proses membuatku takut, seolah-olah aplikasi Anda mati yang bisa membuat DB Anda rusak sekarang. Dengan database klien / server, klien yang sekarat membatalkan transaksi. Bukan untuk mengatakan itu tidak mungkin untuk CS DB rusak tetapi saya pikir itu lebih kecil kemungkinannya daripada memiliki mesin DB dikombinasikan dengan aplikasi.
Andy
5
@Andy, untuk itulah transaksi digunakan. Tidak masalah pada titik mana Anda membunuh mesin DB yang bagus, transaksi tertentu dilakukan atau tidak. Implementasi SQLite dari commit atomic ( sqlite.org/atomiccommit.html ) adalah yang sangat canggih.
Javier
10

  1. Filesystem adalah database. Bukan database relasional, tentu saja, tetapi kebanyakan toko kunci / nilai yang sangat efisien. Dan jika pola akses Anda dirancang dengan baik untuk penyimpanan nilai kunci (misalnya, format repositori git), maka menggunakan database mungkin tidak menawarkan keuntungan signifikan dibandingkan menggunakan sistem file. (Faktanya, ini hanyalah lapisan abstraksi lain yang menghalangi.)

  2. Banyak fitur basis data hanyalah bagasi tambahan. Pencarian teks lengkap? Apakah pencarian teks lengkap masuk akal untuk kode sumber? Atau Anda perlu tokenize berbeda? Ini juga mengharuskan Anda menyimpan file lengkap di setiap revisi, yang tidak biasa. Banyak sistem kontrol versi menyimpan delta di antara revisi file yang sama untuk menghemat ruang, misalnya Subversion dan Git (setidaknya, saat menggunakan file paket.)

  3. Persyaratan lintas platform membuat penggunaan basis data lebih menantang.

    Sebagian besar alat kontrol versi dibangun untuk dijalankan pada berbagai platform. Untuk alat kontrol versi terpusat, ini hanya mempengaruhi komponen server, tetapi masih sulit untuk mengandalkan server database tunggal karena pengguna Unix tidak dapat menginstal Microsoft SQL Server dan pengguna Windows mungkin tidak mau menginstal PostgreSQL atau MySQL. Sistem file adalah penyebut yang paling tidak umum. Namun, ada beberapa alat di mana server harus diinstal pada mesin Windows, dan karenanya memerlukan SQL Server, misalnya SourceGear Vault dan Microsoft Team Foundation Server .

    Sistem kontrol versi terdistribusi menjadikan ini lebih sulit lagi, karena setiap pengguna mendapat salinan repositori. Ini berarti bahwa setiap pengguna membutuhkan database untuk menempatkan repositori ke dalamnya. Ini menyiratkan bahwa perangkat lunak:

    1. Terbatas pada subset platform di mana basis data tertentu ada
    2. Menargetkan backend basis data tunggal yang cross-platform (misalnya, SQLite).
    3. Menargetkan backend penyimpanan pluggable, sehingga orang dapat menggunakan database apa pun yang mereka inginkan (mungkin termasuk sistem file).

    Oleh karena itu, sebagian besar sistem kontrol versi terdistribusi hanya menggunakan sistem file. Pengecualian penting adalah SourceGear's Veracity , yang dapat menyimpan dalam database SQLite (berguna untuk repositori lokal) atau database relasional seperti SQL Server (mungkin berguna untuk server.) Tawaran cloud yang di-hosting-nya dapat menggunakan backend penyimpanan non-relasional seperti Amazon SimpleDB , tapi saya tidak tahu ini benar.

Edward Thomson
sumber
Seperti komentar advokat iblis, sebagian besar orang yang menanyakan pertanyaan "mengapa tidak menggunakan database" tampaknya berarti "mengapa tidak menggunakan RDBMS?" dengan semua kepatuhan ACID dan masalah lain yang terlibat. Fakta bahwa semua sistem file sudah menjadi basis data dari sejenisnya sendiri yang telah dibuang.
mikebabcock
6

Sejauh yang saya lihat dalam banyak penawaran tampaknya file "cukup baik" untuk pekerjaan itu, sesuatu yang masuk akal, dengan mempertimbangkan bahwa pada akhirnya output VCSes juga file.

Ada banyak perusahaan yang menawarkan back end RDBMS dengan antarmuka svn / git / etc, jadi apa yang Anda minta pada dasarnya sudah ada.

Dimitrios Mistriotis
sumber
5

Saya akan mengatakan itu karena struktur data primer dari sistem kontrol versi adalah DAG, yang memetakan ke database dengan sangat buruk. Banyak data juga konten yang bisa dialamatkan, yang juga memetakan ke database sangat buruk.

Integritas data bukan satu-satunya masalah VCS, mereka juga peduli dengan integritas riwayat versi , yang tidak dimiliki oleh database. Dengan kata lain, ketika Anda mengambil versi, Anda tidak hanya perlu memastikan bahwa versi tidak memiliki kekurangan saat ini, tetapi juga bahwa tidak ada dalam seluruh sejarahnya yang telah diubah secara diam-diam.

VCS juga merupakan produk konsumen di samping produk perusahaan. Orang-orang menggunakannya dalam proyek-proyek hobi kecil satu orang. Jika Anda menambahkan kerumitan menginstal dan mengkonfigurasi server database, Anda akan mengalienasi sebagian besar bagian pasar. Saya kira Anda tidak melihat banyak instalasi Vault dan TFS di rumah. Itu alasan yang sama spreadsheet dan pengolah kata tidak menggunakan database.

Juga, ini lebih merupakan alasan untuk DVCS, tetapi tidak menggunakan basis data membuatnya sangat portabel. Saya dapat menyalin pohon sumber saya ke drive jempol dan menggunakannya kembali pada mesin apa pun, tanpa harus mengkonfigurasi proses server database.

Sejauh merusak selama melakukan, VCS menggunakan teknik yang sama persis seperti database untuk mencegah akses simultan, melakukan transaksi atom, dll. Korupsi di keduanya sangat jarang, tetapi mereka memang terjadi . Untuk semua maksud dan tujuan, penyimpanan data VCS adalah database.

Karl Bielefeldt
sumber
1
"peta ke basis data sangat buruk" Namun Vault dan TFS melakukan hal ini. "Integritas data bukan satu-satunya kepedulian VCS, mereka juga peduli dengan integritas riwayat versi, yang tidak dimiliki oleh basis data." Saya gagal melihat bagaimana menyimpan riwayat versi cocok untuk file melalui database terutama karena saya telah menyebutkan produk yang melakukan hal itu. ". Korupsi pada keduanya sangat jarang, tetapi mereka memang terjadi." Tak satu pun dari hasil di halaman pertama berbicara tentang database server Vault yang rusak. Satu tautan yang bahkan berbicara tentang perangkat lunak Vault masalahnya adalah WC menjadi rusak.
Andy
"Untuk semua maksud dan tujuan, penyimpanan data VCS adalah database." Yah ... itu maksud saya. Mengapa tidak menempelkan data saja dalam sistem basis data nyata alih-alih menggulirkan data Anda sendiri?
Andy
2
@Andy Ya, ini adalah database, tetapi tidak semua database dapat saling menggantikan. Setiap basis data memiliki pandangan tertentu tentang dunia (misalnya, SQL DB pada dasarnya menerapkan model relasional). Saat jawaban ini merinci, data yang disimpan oleh VCS dan cara data digunakan tidak cocok dengan model relasional. Saya tidak yakin apakah beberapa NoSQL db lebih baik, tetapi mereka agak baru dan belum membuktikan keunggulan mereka (saya ingat laporan masalah integritas serius untuk beberapa). Dan kemudian ada semua masalah lain di atas itu.
DAG hanya digunakan dalam DVCS (kecuali jika Anda menganggap sejarah linier sebagai DAG yang sangat sederhana, tetapi itu tidak benar-benar abstraksi yang bermanfaat.) Ketika sejarah Anda linear, dengan perubahan monoton yang meningkat, basis data SQL jauh lebih masuk akal .
Edward Thomson
Menambah jumlah versi secara monoton tidak masuk akal bagi VCSes. Saya telah menggunakan cukup banyak dari mereka, dan yang dengan nomor versi terpusat (CVS & SVN menjadi 2 yang paling saya kenal) cenderung menyebalkan. Dan bahkan mereka menggunakan DAG ketika mereka mencoba melakukan penggabungan. Hanya karena representasi penyimpanan mereka tidak didasarkan di sekitarnya tidak berarti itu tidak digunakan.
Mike Larsen
2

  • Pemulihan bencana yang lebih baik (skenario kasus terburuk: kami akan menguraikannya dengan mata, seperti di masa lalu)

  • Membuat pelacakan dan debug bencana seperti itu, mungkin disebabkan oleh kesalahan dalam sistem VCS, lebih mudah.

  • Menurunkan jumlah dependensi. (jangan lupa salah satu sistem penanganan yang kernel, dan lainnya seharusnya)

  • Editor teks selalu tersedia. (Lisensi MS SQL Server ... tidak terlalu banyak)

ZJR
sumber
Jawaban ini sangat buruk. Satu-satunya poin yang benar adalah menurunkan jumlah dependensi. Kedua sistem pendukung harus setara karena Anda harus melakukan pencadangan yang tepat, debugging aplikasi DB tidak lebih sulit daripada debugging aplikasi yang menulis file, dan editor teks selalu tersedia? Saya bahkan tidak tahu apa maksud Anda, karena VCS sendiri tidak akan menggunakan editor teks, dan ADA server DB lain di luar sana (Sqlite, Postgre, MySql, dll.) Sehingga jika Anda INGIN solusi db didukung kurangnya server db seharusnya tidak menjadi faktor.
Andy
1
@Andy ... yang akan digunakan oleh programmer untuk menggunakan editor teks. Anda tahu, pengeditan teks masih tersedia sebagai fungsi sekunder bahkan di IDE favorit Anda.
ZJR
1
@Andy sqliteadalah satu-satunya alternatif yang mungkin untuk file teks, mengingat sejumlah besar skenario terdistribusi yang dilayani DVCS modern. (idk, mungkin Anda mungkin telah melewatkan bagian "terdistribusi" dari DVCS) Hal lain akan terlalu rumit (konfigurasi + firewall + lisensi) atau bahkan konyol untuk didistribusikan . Kemudian lagi melakukan skenario terburuk postmortem ke sqlite mungkin terbukti sulit.
ZJR
1
@ ZJR: Saya tidak berpikir pertanyaan asli yang pernah ditentukan kontrol versi terdistribusi, ia bertanya tentang sistem kontrol versi secara umum. Selanjutnya, argumen editor teks Anda agak datar, karena banyak sistem tidak hanya menyimpan file teks datar. Bahkan git memiliki banyak format file biner (objek longgar, paket file, dll) yang membuat editor teks Anda tidak berguna.
Edward Thomson
@ZJR Bagaimana mengedit kode dalam editor teks dapat dilakukan di backing store VCS? Apakah Anda menyarankan pengeditan secara manual, katakanlah basis data SVN? Selain itu pertanyaan saya tidak terbatas pada DVCS, jadi saya tidak tahu mengapa Anda mengacaukannya.
Andy
2

Fossil adalah Sistem Kontrol Versi Terdistribusi (DVCS) yang sangat baik dan menggunakan SQLite untuk penyimpanan, tidak ada file teks biasa.

Saya sangat suka itu terintegrasi: pelacakan bug, Wiki dan benar-benar didistribusikan. Maksud saya Anda benar-benar dapat bekerja offline dan memperbaiki bug.

Fosil menggunakan Sqlite sebagai format file aplikasi. Dalam keynote di PgCon Dr. Richard Hipp menjelaskan apa keuntungan menggunakan sqlite sebagai Sistem File Aplikasi, dan membuat argumen yang cukup meyakinkan tentang manfaat menggunakan database sebagai sistem file.

Topik utama kedua adalah bahwa SQLite harus dilihat sebagai format file aplikasi — sebuah alternatif untuk menemukan format file sendiri atau menggunakan ZIPped XML. Pernyataan “SQLite bukan pengganti untuk PostgreSQL. SQLite adalah pengganti paku fopen () ”(slide 21). Akhirnya, Richard banyak menekankan fakta bahwa SQLite menangani data Anda (crash safe, ACID) use-the-index.com

Sekarang Dr. Hipp telah membahas masalah tentang menyimpan kode pada basis data

  • Mengapa Fossil didasarkan pada SQLite dan bukannya database NoSQL yang didistribusikan?

Fosil tidak didasarkan pada SQLite. Implementasi Fossil saat ini menggunakan SQLite sebagai toko lokal untuk konten database terdistribusi dan sebagai cache untuk meta-informasi tentang database terdistribusi yang dikomputasi untuk presentasi yang cepat dan mudah. Tetapi penggunaan SQLite dalam peran ini adalah detail implementasi dan tidak mendasar untuk desain. Beberapa versi Fossil di masa depan mungkin menghilangkan SQLite dan mengganti tumpukan file atau database kunci / nilai sebagai pengganti SQLite. (Sebenarnya, itu sangat tidak mungkin terjadi karena SQLite bekerja dengan sangat baik dalam perannya saat ini, tetapi intinya adalah bahwa menghilangkan SQLite dari Fossil adalah kemungkinan teoretis.)

elviejo79
sumber