Masa Depan Kontrol Versi

 (bramcohen.com)
1 poin oleh GN⁺ 2026-03-23 | 1 komentar | Bagikan ke WhatsApp
  • Manyana adalah prototipe kontrol versi berbasis CRDT yang dikembangkan oleh Bram Cohen, menawarkan pendekatan baru untuk menghilangkan konflik merge dan mempertahankan riwayat secara struktural
  • Dengan memanfaatkan CRDT (Conflict-Free Replicated Data Type), merge selalu berhasil, dan konflik ditangani sebagai penanda informasi sehingga pengguna dapat memahami perubahan dengan jelas
  • Inti konsepnya mencakup persistensi urutan baris, merge non-blocking, dan riwayat yang terinternalisasi, serta tidak merusak catatan yang ada bahkan selama proses rebase
  • Ini adalah implementasi tingkat demo yang ditulis dalam sekitar 470 baris kode Python, dan seluruh kode serta dokumen desainnya dipublikasikan di GitHub sebagai domain publik
  • Sebuah contoh eksperimental yang mengajukan model kontrol versi generasi berikutnya tanpa kegagalan merge melampaui keterbatasan Git

Manyana: Visi Konsisten untuk Masa Depan Kontrol Versi

  • Manyana adalah prototipe sistem kontrol versi berbasis CRDT yang dirilis Bram Cohen, sebagai upaya mengatasi masalah konflik merge pada sistem yang ada
  • CRDT menjamin merge selalu berhasil, dan konflik diperlakukan sebagai penanda informatif agar pengguna dapat melihat perubahan yang sebenarnya dengan jelas
  • Pendekatan ini memiliki tiga karakteristik utama: persistensi urutan baris, penanganan konflik non-blocking, dan riwayat yang terinternalisasi dalam struktur
  • Bahkan dalam proses rebase, riwayat yang ada tetap dipertahankan, dan struktur merge kompleks tanpa satu leluhur bersama pun dapat ditangani secara stabil
  • Manyana adalah implementasi demo yang ditulis dalam sekitar 470 baris kode Python, dan dokumen desain serta kodenya tersedia di GitHub sebagai domain publik

Inti Pendekatan Berbasis CRDT

  • CRDT memberikan merge yang selalu berhasil dan eventual consistency yang menjamin hasil yang sama terlepas dari urutan merge
    • Bahkan jika beberapa pengguna mengerjakan branch secara independen lalu menggabungkannya dalam urutan apa pun, hasilnya tetap sama
  • Melalui persistensi urutan baris, jika urutan kode yang disisipkan di posisi yang sama sudah ditentukan sekali, urutan itu akan tetap dipertahankan setelahnya
    • Ini mencegah masalah ketika area konflik diselesaikan secara berbeda di tiap branch
  • Konflik diperlakukan hanya sebagai penanda untuk penyampaian informasi dan tidak memblokir merge
    • Hasil merge selalu dihasilkan, dan konflik ditandai sebagai “bagian yang diubah secara bersamaan di lokasi yang berdekatan”
    • Dengan melacak pelaku dan tindakan dari tiap perubahan, sistem memberikan penanda konflik yang berguna
  • Riwayat terinternalisasi di dalam struktur
    • Status direpresentasikan sebagai struktur ‘weave’ yang mencakup semua baris file, dengan metadata waktu penambahan dan penghapusan pada tiap baris
    • Saat merge, cukup memasukkan dua status tanpa perlu mencari leluhur bersama atau menelusuri DAG, dan hasil yang benar akan selalu dihasilkan

Penanda Konflik yang Lebih Baik

  • Sistem kontrol versi tradisional saat terjadi konflik hanya menampilkan dua blok kode berdampingan, sehingga pengguna harus menafsirkan sendiri perbedaannya
  • Manyana secara eksplisit menandai tiap area konflik dengan keterangan seperti “dihapus”, “ditambahkan”, dan menunjukkan siapa yang melakukan perubahan apa
    • Misalnya, jika satu pengguna menghapus fungsi dan pengguna lain menambahkan satu baris di dalam fungsi tersebut, Manyana menampilkan struktur tiap perubahan dengan pemisahan yang jelas
    • Dengan begitu, pengguna tidak perlu membandingkan dua blok secara manual, melainkan bisa langsung memahami makna dan konteks perubahan

Mendefinisikan Ulang Rebase

  • Dalam sistem berbasis CRDT, rebase tidak merusak riwayat
    • Rebase konvensional menumpuk ulang commit di atas base baru dan menciptakan riwayat fiktif
    • Di Manyana, efek yang sama dapat diperoleh sambil tetap mempertahankan seluruh riwayat asli
  • Untuk itu, cukup tambahkan anotasi “primary ancestor” pada DAG
  • Pendekatan ini tetap bekerja stabil bahkan pada struktur merge tanpa leluhur bersama, sehingga dapat menghindari kegagalan merge 3-way tradisional

Status Proyek Saat Ini

  • Manyana adalah implementasi demo, bukan sistem kontrol versi yang lengkap, dan bekerja pada tingkat file individual
    • Terdiri dari sekitar 470 baris kode Python
    • Fitur Cherry-pick dan local undo belum diimplementasikan, tetapi arah pengembangan selanjutnya dijelaskan dalam README
  • Proyek ini membuktikan bahwa kontrol versi berbasis CRDT dapat menyelesaikan masalah UX dan memberikan hasil yang lebih baik daripada alat yang ada
  • Seluruh kode didistribusikan sebagai domain publik (public domain), dan dokumen desain lengkap disertakan dalam README GitHub

Ringkasan Reaksi Komunitas

  • Seorang pengguna menilai bahwa meski Git telah digunakan lebih dari 10 tahun, paradigma kontrol versi baru tetap dibutuhkan, dan menyebut upaya Manyana secara positif
    • Ia menilai konsep merge yang selalu berhasil belum terasa intuitif dan meminta contoh serta penjelasan tambahan
    • Ia menunjukkan minat pada ide perbaikan rebase, dan menyebut bahwa dalam proyek pribadinya ia memakai metode pengelolaan merge melalui branch perantara
    • Ia juga menyoroti keterbatasan Git dalam penanganan file biner, kebingungan pembedaan branch kiri/kanan, serta kurangnya ringkasan perubahan kode berskala besar
    • Ia mengusulkan agar kontrol versi di masa depan mendukung fitur token-aware atau plugin berdasarkan bahasa dan format file
  • Pengguna lain bertanya apakah Manyana memiliki dasar yang mirip dengan Pijul atau Darcs, sambil meminta perbandingan antara masalah performa Darcs dan status terkini Pijul

Kesimpulan

  • Manyana adalah demo nyata penerapan CRDT pada kontrol versi, yang mendesain ulang secara mendasar penanganan konflik dan masalah rebase
  • Struktur tanpa kegagalan merge, konflik sebagai informasi, dan riwayat yang terinternalisasi secara struktural menunjukkan arah desain yang melampaui keterbatasan model Git saat ini
  • Meski belum menjadi sistem yang lengkap, ini adalah titik awal yang bermakna sebagai cetak biru perancangan sistem kontrol versi generasi berikutnya

Bacaan terkait

1 komentar

 
GN⁺ 2026-03-23
Komentar Hacker News

  • Menurut saya, cara menampilkan merge adalah masalah yang terpisah dari cara merepresentasikan histori
    Saya juga tidak suka UI merge bawaan Git, jadi saya memakai p4merge. Ini alat yang menampilkan empat panel (kiri, kanan, base bersama, hasil), jadi penyebab konflik dan cara menyelesaikannya bisa langsung terlihat
    Saya rasa tidak perlu sampai mengganti VCS-nya sendiri

    • Bahkan tanpa memakai p4merge, jika mengubah pengaturan Git merge.conflictStyle menjadi "diff3" atau "zdiff3", versi base juga akan ditampilkan
      Dengan begitu, hanya dari marker konflik pun kita bisa menebak sisi mana yang menambahkan kode baru
    • Kebanyakan orang tidak memikirkan masalah ini secara mendalam
      Dulu saya terkejut mendengar di sebuah podcast ada tamu yang membuat VCS baru tetapi salah memahami cara Git menyimpan diff. Kalau setelah bertahun-tahun mengerjakan proyek pun konsep dasarnya tidak pernah dicari, rasanya semangat NIH (reinvention) memang masih hidup
    • Saya juga merekomendasikan p4merge. Jika merge di Git terasa menyiksa, itu lebih merupakan masalah desain UX daripada masalah konsep
    • IDE JetBrains (IntelliJ, dll.) juga menyediakan UI merge yang sangat bagus
      Namun jika ditangani di level SCM, ada keuntungan karena sistem bisa mengingat riwayat merge pengguna. Git punya beberapa edge case di bagian ini
    • Saya penasaran apakah ini juga bisa dipakai untuk merge direktori biasa

  • Saya tidak yakin merge yang tidak pernah gagal itu benar-benar hal yang baik
    Kegagalan merge sering kali bukan sekadar konflik posisi, tetapi sinyal adanya konflik semantik. Dalam kasus seperti itu, memang harus ditangani secara manual

    • Sistem yang diusulkan katanya tetap menampilkan perubahan yang saling bertumpang tindih kepada pengguna. Perbedaannya dengan Git tampaknya hanya soal nilai default
    • Dalam praktiknya, meskipun merge berhasil, kadang hasilnya tetap berupa kode yang tidak bisa dikompilasi. Saya pernah mencoba menyelesaikan konflik merge dengan alat AI, tetapi terutama saat rebase hasilnya kurang bagus
    • Sistem ini bukan berarti tidak gagal, melainkan memungkinkan kita tetap melanjutkan merge sambil menandai konflik. jj juga mengambil pendekatan serupa
    • Mengandalkan merge teks sederhana untuk menangkap masalah semantik ada batasnya. Sebagai gantinya, menurut saya pemeriksaan pasca-merge atau verifikasi niat berbasis agen akan lebih baik

  • Saya rasa CRDT tidak cocok untuk version control
    Konflik adalah inti dari version control. Jika dua pengembang mengubah kode ke arah yang berbeda, pada akhirnya tetap dibutuhkan pilihan semantik. Dalam situasi seperti ini, CRDT berisiko menghasilkan kode yang aneh
    Sudah ada banyak alat di atas Git yang memberi UX merge lebih baik, dan kemudahan cherry-pick atau revert juga merupakan keunggulan Git

    • Tentu saja merge otomatis hanya menyelesaikan konflik sintaktis, sedangkan konflik semantik tetap ada
      Misalnya di satu branch sebuah konstanta dihapus, sementara di branch lain konstanta itu digunakan, maka kodenya akan rusak
      Karena konflik Git kebanyakan adalah masalah sintaktis, pendekatan semantic merge yang lebih cerdas atau pendekatan CRDT mungkin bisa membantu
    • CRDT bisa saja dipakai hanya untuk menghitung merge
      Misalnya untuk melacak nama file, properti, hash, dan sebagainya, kita bisa memakai OR-set(https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type).
      Namun penyelesaian konflik tetap harus ditangani di antarmuka eksternal

  • Saya tidak begitu paham mengapa fokusnya ke CRDT
    Masalah semantik dalam konflik tetap ada. Bahkan perubahan bisa terlihat saling menyisip (interleave) sehingga justru lebih membingungkan
    Saya adalah penganut rebase-sentris. Merge commit sebaiknya dihindari, dan semua commit harus menjadi unit yang mandiri. Menurut saya Gitflow adalah anti-pattern
    Jujutsu atau Gerrit jauh lebih baik dalam menyelesaikan masalah Git yang sebenarnya, yaitu “mengelola rantai commit berdasarkan feedback review”

    • Yang penting adalah apa yang dimaksud dengan “unit of work”
      Git menerapkan ulang snapshot, sehingga seolah-olah pekerjaan yang sama ada dua kali. Sebaliknya, Pijul bekerja dalam unit patch, sehingga hasilnya sama terlepas dari urutan. Menurut saya itulah unit kerja yang benar-benar independen
    • CRDT dapat memperlakukan merge dan rebase sebagai konsep yang sama
      Bahkan dalam keadaan ada konflik, commit tertentu masih bisa dibatalkan (undo). Strukturnya bisa lebih fleksibel dibanding Git
    • Kalau selalu memakai rebase, kita harus menyelesaikan konflik di setiap commit, jadi tidak efisien
      Dalam praktiknya, yang penting sering kali hanya hasil akhir. Menggabungkan squash merge dengan tepat lebih realistis
    • Orang mudah mengira CRDT menyelesaikan semua masalah
      Padahal ada masalah yang pada dasarnya memang perlu konflik. Misalnya fenomena karakter tercampur di editor kolaboratif, yang justru bisa menghasilkan hal yang lebih buruk

  • Proyek ini terasa seperti pengembangan dari ide Codeville yang dulu dibuat Bram
    Codeville muncul pada masa booming DVCS di awal 2000-an, dan memakai penyimpanan dan merge berbasis weave. Ini konsep yang 10 tahun mendahului CRDT, tetapi idenya mengalir secara alami ke sana
    Menyenangkan melihat Bram masih terus menggarap masalah ini dengan pendekatan baru

    • Keunggulan CRDT yang sebenarnya adalah model perilakunya mudah dipahami. Kalau mencoba mengimplementasikannya sendiri, strukturnya akan terasa jelas
    • Pada 2007, Bram pernah mengatakan bahwa algoritma Causal Tree saya adalah variasi dari weave. Setelah itu algoritma keluarga weave berkembang cukup banyak, dan ada juga paper terkait
      arxiv:2002.09511
    • CRDT bukan satu teknologi tunggal, melainkan kerangka konseptual. Pada akhirnya Git juga mengimplementasikan eventual consistency, jadi dalam arti luas bisa dianggap sebagai CRDT

  • Saya tidak setuju dengan pernyataan “belum ada VCS berbasis CRDT”
    Pijul sudah ada, dan itu proyek yang dikerjakan para ahli selama ribuan jam

    • Ini bukan berarti Bram jarang berurusan dengan VCS. Codeville saja sudah ada sejak 20 tahun lalu
    • Saya punya hobi mengecek halaman teori di manual Pijul setiap tahun. Sampai sekarang kesalahan formatting TeX-nya belum juga diperbaiki
      Sudah 6 tahun dalam tahap eksperimen, dan 4 tahun lalu saya sendiri sempat mengirim issue, tapi masih belum ditindaklanjuti
    • Awalnya saya menemukan repositori GitHub yang lama, tetapi repositori resmi yang sebenarnya ada di Nest.
      Pijul adalah VCS yang dikembangkan dengan dirinya sendiri, jadi tidak memakai GitHub
    • Kadang saat menjalankan pijul pull -a, muncul konflik sehingga saya biasanya langsung clone ulang. Saya penasaran apakah ada pull untuk update pelacakan

  • manana.py adalah kode Python tanpa dependensi sepanjang 473 baris
    Implementasi sebenarnya hanya sekitar 240 baris, sisanya adalah kode test. Sederhana tapi mengesankan

    • Namanya sendiri adalah lelucon. “Mañana” dalam bahasa Spanyol berarti besok, tetapi juga bisa bermakna “nanti saja”, jadi mengisyaratkan prokrastinasi
    • Menakjubkan ada hal seperti ini yang dibuat dengan Python rapi hanya dalam beberapa ratus baris
      Mengingat insiden left-pad di ekosistem JS, saya rasa Python juga perlu lebih banyak paket kecil yang bertanggung jawab seperti ini

  • Sistem seperti ini seharusnya dirancang dengan menganalisis pola konflik merge berdasarkan ukuran tim
    Tim berisi 1, 10, 100, atau 1000 orang masing-masing menghadapi masalah yang berbeda, dan perlu dipertimbangkan juga bagaimana pengembangan berbasis agen akan mengubahnya
    Dari pengalaman saya, pada skala 1 sampai 100 orang, kode biasanya dibagi menjadi subtree per tim sehingga hampir tidak ada konflik.
    Jika jumlah agen bertambah, mungkin 100 orang bisa terasa seperti 1000 orang, tetapi untuk sekarang rasanya solusinya muncul lebih dulu daripada masalah nyatanya

    • Agen bisa menangani sistem version control apa pun
      Sekarang cukup serahkan konflik merge ke Codex dan selesai, jadi alasan untuk memakai VCS baru pun berkurang
      Git dirancang untuk tim besar, dan di era agen hal seperti ini cukup ditangani lewat otomatisasi proses
    • Bahkan saat ukuran tim membesar, secara alami akan muncul spesialisasi per area kode, sehingga frekuensi konflik cenderung tetap mirip.
      Masalah justru lebih sering muncul pada bottleneck library bersama atau kebijakan pembatasan akses
    • Pendekatan berdasarkan ukuran tim justru terasa tidak efisien. Yang penting adalah desain yang konsisten secara konseptual

  • Masalah yang lebih besar daripada konflik adalah skalabilitas Git
    Ukuran repositori dan laju perubahan sudah mendekati batas. Diperlukan desain ulang menyeluruh pada server, klien, dan protokol

    • Saya penasaran masalah skalabilitas seperti apa yang dimaksud. Apakah karena monorepo?
    • Salah satu solusinya adalah memodularisasi kode dan mereferensikannya lewat dependensi versi

  • Secara pribadi saya kurang paham masalah apa yang sebenarnya ingin diselesaikan sistem ini
    Secara abstrak memang menarik, tetapi dalam praktiknya jj jauh lebih praktis daripada Git
    Menurut saya langkah berikutnya adalah sistem version control yang bekerja di level AST, bukan level file.
    Sudah ada percobaan seperti LightTable atau Dark; akan menarik jika VCS berbasis tree seperti itu benar-benar diuji

    • Pendekatan ke arah itu sebenarnya sudah sedang berjalan. Mereka sedang membangun sistem parser baru