İşbirlikli düzenleme hakkındaki yalanlar, Bölüm 1: Çevrimdışı düzenleme algoritmaları

• Moment’in temel metin editörü için işbirlikli düzenlemeyi değerlendirmesi sonucunda, CRDT ve OT ailesi algoritmaların çevrimdışı doğrudan çakışmalarda kullanıcıların veri bozulması olarak görebileceği birleştirme sonuçları üretebildiği görüldü
• Alice’in tüm cümleyi silip Bob’un Colorı Colour olarak değiştirdiği basit bir örnekte bile, son belgede yalnızca u harfinin kalması gibi insanların amaçlamadığı sonuçlar ortaya çıkabiliyor
• Moment’in kullanım senaryolarında denenen doğrudan çakışmaların yaklaşık %20–30’u kabul edilemez bulundu; görülme sıklığı ve olumsuz tepkiler nedeniyle bunun ürün deneyimi olarak savunulmasının zor olduğu düşünüldü
• Yjs, ShareJS ve Peritext çevrimdışı düzenlemeyi, uzun gecikmeli işbirliğini veya bağımsız kopyaların otomatik birleştirilmesini öne çıkarıyor; ancak algoritmalar kullanıcının niyetini ve sıralamayı bilemediği için sezgisel yöntemlere dayanıyor
• Çevrimdışı işbirlikli düzenleme yalnızca algoritma sorunu değil, daha çok bir UI/UX sorunu; git birleştirme arayüzü veya Ink & Switch’in collaborative history yaklaşımı gibi, insanların okuyup karar verebileceği bir birleştirme deneyimi gerekiyor

---

Moment’in işbirlikli düzenleme değerlendirmesinde ortaya çıkan sınırlar

• 2024’ün başlarında Moment, temel metin editöründe kullanacağı işbirlikli düzenleme sistemini araştırmaya başladı
• Çeşitli algoritmalar yalnızca çevrimiçi eşzamanlı düzenlemeyi değil, kullanıcıların sınırsız bir süre çevrimdışı düzenleme yaptıktan sonra tekrar çevrimiçi olduklarında değişikliklerin otomatik birleştirilmesini sağlayan çevrimdışı senaryoları da çözdüklerini iddia ediyordu
• Makaleleri ve sunumları ilk gördüklerinde, işbirlikli düzenleme topluluğunun problemin geneline dair “doğru cevaba” ulaştığını umdular
• Değerlendirme sürecinde CRDT ve OT ailesi algoritmalar doğrudan düzenleme çakışmalarını sezgisel olmayan şekilde çözdü; kullanıcılar da bu sonucu veri bozulması olarak algıladı
• Çevrimdışı düzenleme doğrudan çakışma olasılığını ciddi biçimde artırdığı için, Moment’in istediği çevrimdışı düzenleme deneyimini yalnızca bu algoritmalarla oluşturmak zordu

Silme ile yazım düzeltmesinin çakıştığı basit bir örnek

• Alice ve Bob aynı belgeyi çevrimdışıyken düzenler
• Belgede The Color of Pomegranates metni vardır
• Bob, Color yazımını İngiliz İngilizcesindeki Colour biçimine çevirir; Alice ise metnin tamamını siler
• İkisi daha sonra çevrimiçi olduğunda bu iki düzenleme çakışır ve sistem, hangi düzenlemenin önce yapıldığını bilmeden bunları uzlaştırmak zorunda kalır
• Bu örnekte Alice ve Bob, sonunda içinde yalnızca u harfi bulunan bir belge elde eder
  • Bu ne geçerli bir cümledir ne de geçerli bir kelime
  • Kullanıcılar böyle bir sonucu Moment’in kendi verilerini bozması olarak görür

Doğrudan çakışmalarda tuhaf sonuçlar nadir değil

• Bu çakışma basit ve doğrudan bir düzenleme çakışmasıdır, ancak popüler işbirlikli düzenleme algoritmalarının desteklediği kabul edilebilecek kapsamın içindedir
• Gerçek sonuç, bir insanın kendi başına yazmayacağı bir belgeydi ve Moment ürününün verileri bozması olarak yorumlandı
• Kullanım senaryosuna göre değişmekle birlikte, Moment’in denediği doğrudan çakışmaların kabaca %20–30’u çevrimdışı düzenleme kullanım senaryosu için kabul edilemez sonuçlar verdi
• Olumsuz geri bildirimler ve görülme sıklığı birlikte değerlendirildiğinde, böyle sonuçları kullanıcılara açıklayıp savunmanın zor olduğuna karar verildi

Araçların öne sürdüğü çevrimdışı düzenleme desteği

• İlk başta bu sonuçlar ortaya çıkınca, bu araçların sunduğu şeyin yanlış anlaşıldığı düşünüldü
• Ancak her projenin açıklamaları, ilgili senaryonun destek kapsamı içinde olduğu şeklinde okunabiliyor
  • Yjs, README’de offline editing desteğini açıkça belirtiyor
  • ShareJS, sıfır gecikmeden uzun bir tatil süresine varan gecikmelere kadar her durumda işbirliği yapılabileceğini söylüyor
  • Peritext, kullanıcıların bir belgenin bağımsız kopyalarını düzenleyebileceğini ve bunların, kullanıcının niyetini mümkün olduğunca koruyacak şekilde otomatik birleştirilebileceğini açıklıyor
• Moment hâlâ bu soruna bir çözüm arıyor, ancak pratikte görülen hataların sıklığını ve türlerini bu iddialarla bağdaştırmanın zor olduğunu düşünüyor

Uzlaştırmasız algoritmaların temel sınırı

• Değerlendirme ilerledikçe, söz konusu algoritmaların Moment’in istediği davranışı göstermediği sonucuna varıldı
• Geriye kalan soru, bunun katkı yapılarak düzeltilebilecek bir sorun mu, yoksa algoritmanın temel bir sınırı mı olduğuydu
• Bunun temel bir sorun olarak görülmesinin üç nedeni var
  • Algoritma Alice ve Bob’un niyetini bilemez; ikisine ne istediklerini e-postayla soramaz veya GitHub Pull Request arayüzündeki gibi inceletemez
  • Alice’in tümünü silme önerisini ve Bob’un yazım düzeltmesi önerisini alıp sonucu sezgisel yöntemlerle belirlemek zorundadır
  • Karakter düzeyinde çalışır ve çıktı hakkında yalnızca çok zayıf garantiler sunar
  • Alice ve Bob, diğerinin ne yaptığını bilseydi düzenleme yapıp yapmama kararını farklı verebilirdi
• Bu algoritmalar, nedensel sırayı izleyememe sorunuyla da bağlantılıdır

Çevrimdışı düzenleme daha çok bir UI/UX sorunu

• Moment, zorlu algoritmayı uygulayınca gerçek çevrimdışı düzenleme desteğini yan ürün olarak elde edebileceğini umuyordu; ancak değerlendirme sonrasında bunu böyle görmek zorlaştı
• Kullanıcıların algoritma sonucunu veri bozulması olarak görmesi haklıydı; tuhaf sonuçlar algoritmanın doğasında vardı ve gerçek bir sorun olacak kadar sık gerçekleşebiliyordu
• Bir başka yorum, işbirlikli düzenlemeye kayda değer UI/UX kaynağı ayırmak gerektiğidir
• Algoritma sorunu tamamen çözemez, ancak çözümün bir parçası olarak rol oynayabilir

git birleştirme arayüzü ve araştırma yönü

• Zaten yaygın biçimde benimsenmiş bir belge birleştirme arayüzü olarak git var
• Araştırma sorusu, bu deneyimin ne kadar daha erişilebilir, anlaşılır ve otomatik hale getirilebileceğine daha yakındır
• 2009 civarında, git’in değişiklikleri otomatik birleştirmek için kullandığı algoritmalar üzerine çok tartışma vardı
  • git, Myers O(ND) diff algorithm algoritmasını benimsedi; bu algoritma esas olarak biyologların BLAST türü dizi analizlerinde kullandığı bir algoritmaydı
  • Bram Cohen, diff sonuçlarının sezgisel olmadığını düşünerek patience diff algorithm algoritmasını geliştirdi; bu da artık geliştirilmesi durmuş git rakibi bzr tarafından benimsendi
• O dönemde tartışma, insanların okuyabileceği diff’ler üretmeye odaklanıyordu; bugünkü tartışma ise algoritmanın insan müdahalesi olmadan bu sonuca ulaşıp ulaşamayacağına daha yakın
• Ink & Switch tarafından geliştirilen collaborative history gibi, işbirlikli düzenlemeyi UI/UX sorunu olarak ele alan araştırmalar devam ediyor

[GN⁺]

Hacker News yorumları

• Eg-walker ve ShareJS’in yazarıyım. Yazı, çalışmalarıma karşı bir tondaymış gibi görünüyor olabilir ama aslında tamamen katılıyorum ve HN’de de yıllardır aynı şeyi söylüyorum.
  Günümüz gerçek zamanlı iş birliği araçları, herkes çevrim içiyken birlikte düzenleme yaptığında iyi çalışıyor; ancak kullanıcılar çevrim dışıyken ya da uzun ömürlü dallarda düzenleme yapıyorsa birleştirme sırasında çakışma gösterimi ve elle inceleme seçeneği gerekiyor. Özellikle kodda bu daha da geçerli.
  Neyse ki egwalker gibi algoritmalar tüm kullanıcıların karakter düzeyindeki düzenleme izlerini ve nedensel sıralamayı, yani Git DAG’ine benzer değişiklik sırasını sakladığı için Git’ten çok daha fazla bilgiye sahip. Bu yüzden dalları birleştirirken çakışma aralıklarını tespit edip gösterebilen ve kullanıcının bunları elle çözmesini sağlayan bir CRDT yapmak mümkün olmalı.
  Algoritmik açıdan ilginç ama yeterince çözülebilir bir problem gibi görünüyor; garip şekilde metin düzenleme tarafında neredeyse kimse bunu denememiş gibi. Bu alana özgün ve değerli bir katkı yapmak istiyorsanız, bu CRDT ekosisteminde eksik olan önemli bir parça; birinin denemesini isterim.
  [1] Bu yorumun alt tarafı: https://news.ycombinator.com/item?id=19889174

  • Bunu yapınca sonuçta veri modelinin bir parçası olarak çakışmayı eklemiş oluyorsunuz. CRDT’deki C’yi, yani “conflict-free” olmayı başarmanın ilginç bir yolu; ama tamamen meşru ve belki de tek yol olabilir.
    Bir sonraki ilginç mesele, çakışma çözümünün kendisi etrafında çakışmalar oluştuğunda ortaya çıkıyor.
  • Joseph, çalışmanın kötü olduğunu söylemek istememiştim. Niyetim, uygulayıcıların ne bekleyebileceklerini anlamalarına yardımcı olmak ve sonda söylediğin türden problemler için motivasyon sağlamaktı.
    Bu tür sistemleri değerlendirmek başlı başına yeterince zor bir teknik problem; bu yüzden birçok ekibin zorlanacağını düşünüyorum. Bu yüzden pratik tavsiyeyi hak ediyorlar ve bizim de bunu daha erken bilmiş olmayı dilediğimizi hissediyorum.
  • Algoritmik bir çözümün mümkün olup olmayacağı konusunda şüpheliyim, ama bunun üstündeki UX katmanında ele alınabileceği görünüyor. Örneğin istemci, düzenleme izlerine dayanarak çakışmaları tespit edip çözüm sonucunu yeni bir düzenleme olarak oluşturan bir çakışma çözme iletişim kutusu gösterebilir.
    Zor kısım, çakışmanın çözüldü olarak işaretlenmesi. CRDT’ye bir alan eklemek kadar basit de olabilir; o durumda bunun da algoritmik bir çözüm sayılıp sayılmayacağını bilmiyorum.
    [1] https://josephg.com/blog/crdts-go-brrr/
  • Yazı, birbiriyle örtüşen eşzamanlı splice örneklerini ele alıyor; bu iyi bilinen tuhaf bir sınır durumu.
    Program kodu düzenlemesi söz konusuysa, birleştirme sonucunun geçerli bir program olmasını beklersiniz; bu da çok daha derin bir tavşan deliğine dönüşür. JetBrains’te bu problemi AST tabanlı birleştirme ile çözmeye çalışan bir proje olduğunu, ancak çok daha derine indikten sonra buna değmeyeceğine karar verdiklerini duydum.
  • “Çevrim dışı” düzenlemenin bir insan problemi olduğunu, otomasyonla çözülemeyeceğini düşünüyorum. İnsanlar otomasyonu ya da sistemi bozmanın veya etrafından dolaşmanın yolunu bulur.
    İnsanların kullandığı belgelerde izin verdiğim “çevrim dışı düzenleme” yalnızca yorum eklemektir. Düzenleme yok, otomatik birleştirme yok.
    Otomasyonun konusu olan kaynak kodundaki “çevrim dışı düzenleme” için Git kullanıyoruz; Git de birleştirmeyi çözdüğünü iddia etmez, yalnızca revizyonları gösterir. Birleştirme, insan denetiminde ya da en iyi tahminle uzman otomasyon tarafından yapılan bir iştir; başarının doğrulanması için hâlâ inceleme ve test gerekir.

• Mekanik birleştirme algoritmaları, çakışma türüne göre daha iyi ya da daha kötü performans gösterebilir; ama sonuçta hiçbir CRDT, birleştirilmiş metnin kullanıcının söylemek istediği şey olup olmadığını判断layamaz.
  Upwelling makalesi, yazıda anlamsal çakışma ile dilbilgisel çakışma diye adlandırdıkları farkı daha ayrıntılı ele alıyor: https://inkandswitch.com/upwelling/
  Ciddi iş birliğinin sonunda bir belge inceleme problemi de olduğunu düşünüyorum. Gazetecilikte ya da bilimsel yayıncılıkta özellikle böyle; toplantı notlarında ise çoğunlukla göz ardı edilebilir.

  • Peter, güzel sözlerin için teşekkürler. Yazının önemli bir kısmının, sonunda doğrudan değindiğin Ink & Switch çalışmasını motive edecek şekilde bittiğini görmeni isterim.
    Upwelling’e de bağlantı vermek istiyordum ama adını hatırlayamadım; teslim tarihi yüzünden yerine başka bir bağlantı kullandım.

• CRDT uygulamalarının bir başka karanlık tarafı da altyapı yükü. Geçmişte bunu derinlemesine yazmıştım[0] ve Supabase’in de birkaç yıl önce Postgres için CRDT uzantısı yazısında[1] benim deneysel bulgularımla aynı sonuca vardığını görmek sevindiriciydi.
  CRDT kullanacaksanız Redis gibi bir şey kullanmak ya da bellek kullanımı düşünmesi bile acı verse de MyRocks[2] ya da RocksDB/LevelDB tabanlı bir şey kullanmak daha iyi. Ne yaparsanız yapın, arka uç olarak RDBMS, özellikle de Postgres koymamalısınız.
  [0]: https://news.ycombinator.com/item?id=40834759
  [1]: https://supabase.com/blog/postgres-crdt
  [2]: http://myrocks.io

  • Yjs + Postgres ile kendim geliştirdiğim için gerçekten faydalı görünüyor. Bir gün büyük bir krizi atlatmamı sağlayabilir.

• Bu yazıdaki gözlemler doğru. CRDT, dağıtık veri yapıları için harika bir biçimsel model; ancak tüm çatışmaları otomatik olarak çözmesi gerektiği fikri, adının da söylediği gibi çatışmasız çoğaltılmış veri tipi düşüncesi, bana hep rahatsız edici gelmiştir.
  Yazının gösterdiği gibi bunun umutsuz bir çaba olduğunu düşünüyorum. Gereken şey, çatışmaları paylaşmayı ve işbirliğiyle çözmeyi mümkün kılan düzgün bir yapısal gösterim; kontrolü kullanıcıya geri vermeli ve çözüm sürecini desteklemeli. Sevdiğim makalelerden biri olan “Turning Conflicts into Collaboration” [1] bu fikri ikna edici biçimde ele alıyor.
  Devam eden doktora araştırmam kapsamında, kafes teorisine dayalı yapısal çatışma gösterimi için biçimsel bir model olan “Lazy Merging: From a Potential of Universes to a Universe of Potentials” [2] geliştirdim. Tesadüfen bu da bir CRDT, ama çatışmaları otomatik çözmeye çalışmıyor; onları işbirliğine dayalı belgenin içinde temsil ediyor. Matematiksel yaklaşınca, tekrar tekrar birleştirilmiş mevcut çatışmalardan sonra bile birleştirmenin tamlığı, minimalliği ve tekilliği gibi güçlü özellikleri garanti eden basit bir kavramsal modele ulaşabildim; birleştirme hesaplaması da çok kolay.
  [1] https://doi.org/10.1007/s10606-012-9172-4
  [2] https://doi.org/10.14279/tuj.eceasst.82.1226

  • CRDT’yi ilk öğrendiğimde açılımı commutative replicated data types, yani değişmeli çoğaltılmış veri tipleriydi. Shapiro ve diğerlerinin makalesinde de böyleydi; telaffuzu daha zor ama ben bunu daha çok seviyorum.
    Çatışma karmaşık bir kavram ve “conflict-free” sonucu tanımlayan bir ifade olarak teknik açıdan doğru olsa da, bu yazıda ve yukarıdaki yorumda görüldüğü gibi yanlış anlamalara yol açabiliyor.
    Değişmelilik, Bob değişiklikleri [Bob, Alice] sırasıyla, Alice ise [Alice, Bob] sırasıyla uygulasa bile ikisinin de aynı belgeye ulaşması özelliğidir. Daha yüksek bir soyutlama düzeyinde belgenin anlamlı bir biçimde “çatışmasız” olduğu anlamına gelmez.

• Birden fazla farklı öznenin gerçek zamanlı koordinasyon olmadan aynı anda tek bir veri parçası üzerinde yetkiye sahip olması kavramının genel olarak çözülemez olduğunu düşünüyorum. Bu, dağıtık sistemlerden zaten öğrendiğimiz bir ders; belge üzerinde dağıtık düzenlemeyi düşününce bu yazıda da gayet iyi görünüyor.
  Uçak kokpitindeki çift giriş, çocuk yetiştirme ve akla gelebilecek başka farklı örneklerde de aynı ilke geçerli gibi.

  • Çözülebilir, ama birçok kişinin girmeye üşeneceği daha karmaşık bağlam bilgisi gerekir. Örneğin “az önce değiştirdiğim bu kelime yalnızca bu cümlenin tamamının parçası olduğunda anlamlı ve o cümlenin tamamı da paragrafın bütünü için şart değil” gibi bilgiler.
    Ayrıca buna “çözülebilir” demek de komik; çünkü şu anda dünyanın büyük bir kısmı, hesaplamanın nihai sonucunu LLM’lerin kaotik çıktısına yakın bir şeyin belirlemesini düşünüyor olabilir.
  • Bu, dağıtık veri depolama için Brewer’ın CAP teoremidir. Üçünden yalnızca ikisine sahip olabilirsiniz: tutarlılık, kullanılabilirlik, bölüm toleransı.

• İşbirliğine dayalı metin düzenlemede yaygın kullanılan algoritmalar olan CRDT ve OT, düzenleme işlemlerinin ne yaptığı ve nasıl etkileştiği konusunda katı cebirsel gereksinimlere sahiptir.
  Bu yüzden sunucu “Colour” örneğini UX açısından makul şekilde ele alacak kadar akıllı olsa bile, iyimser istemci tarafı düzenleme için buna karşılık gelen CRDT/OT’yi tasarlamak çok zordur.
  CRDT/OT kullanmazsanız bunu aşabilirsiniz. Örneğin sunucu işlemleri aldığı sırayla işler ve istediğiniz UX mantığını uygular; istemci de bunun üzerinde iyimser düzenlemeye izin vermek için rebase/tahmin stratejisi kullanır. Bkz: https://doc.replicache.dev/concepts/how-it-works
  Bunu metin düzenlemeye uygulamanın da zorlukları var, ancak bunlar burada tartışılan CRDT/OT sorunundan ayrı.

  • Bu yorum çok az değer görmüş; tamamen katılıyorum.

• Bunun, matematiksel, nedensel ve entropik çatışma kavramlarının anlamsal çatışma ile birbirine karıştırılmasından kaynaklandığını düşünüyorum. Ben de bir zamanlar ters yönde aynı hatayı yapmıştım ve ne dediğimi bilmediğim bana net biçimde söylenmişti.
  Ağaçları dikkate almaya başlayınca işler çok daha dağınık hale geliyor. Örneğin yJS, JSON belgeleri üzerinde çalışır. UI yalnızca sığ seviyeyi gösteriyor ve derin seviyeler açılmamışsa, kullanıcı silinen düzenlemeyi hiç görmeyebilir.
  Çatışmaları koruyan CRDT sınıfları içinde, hatırladığım kadarıyla bir register’ın birden fazla değer alabilmesi en umut verici seçenek gibi görünüyor. Kullanıcıya bu tür çatışmalar sunulmalı; hatta tamamen görsel olarak da gösterilebilir. Geçmişe göz atabilmeyi sağlamak da, tuhaf bir şeyin nasıl ortaya çıktığını veya kendi değişikliğinin nasıl kaybolduğunu kullanıcının anlamasını sağlayan pratik bir alternatif gibi görünüyor.

  • Bu tür bir CRDT için “Git” adı güzel olurdu.
  • Bu açıdan Loro umut verici görünüyor. Bu sorunu aktif olarak ele alıyor.

• Torvalds’ın kendisinin de otomatik birleştirmeyle nelerin başarılabileceği konusunda epey kötümser olduğunu hatırlıyorum. Ve bu değerlendirme doğruydu.
  Git’in, yeterince akıllı bir algoritmanın otomatik olarak doğru şeyi yapması yoluyla bir sürüm kontrol sisteminin “birleştirme sorununu çözebileceği” ya da çözmesi gerektiği fikrini reddettiğini söylemişti.
  Çevrimdışı düzenlemenin bir UI/UX sorunu olduğuna katılıyorum. Daha derindeki neden, bilişim sektörünün eski çözümleri tekrar etme alışkanlığı ve “genel olarak 5 librelik bir torba 10 librelik bir torbadan daha kullanışlı olduğuna göre, 10 libre eşya tek bir 5 librelik torbaya konmalı” inancı.
  “Metin editörü”nün temel imgesi Mosaic textarea, MacWrite ya da ikisinin arasında bir şey olduğundan, genelde birleştirmeyi bunun üstüne en az değişiklikle eklemeye çalışıyorlar. Menü öğesi ya da küçük bir iletişim kutusundaki birkaç seçenek gibi. Menünün derinlerinde GUI birleştirme desteği olsa bile ya programcılara yönelik diff/merge korku gösterisi düzeyinde kalıyor ya da sisin içinde gemi kullanmak gibi tehlikeli, üstü çizili metin tabanlı bir görünümden ibaret oluyor.
  Ama çevrimdışı iş birliği içeren metin düzenlemede kısmen elle birleştirme sürecin merkezindedir ve editör tasarımının merkezinde de olmalıdır. Ne yazık ki MacWrite, kaçması zor bir yerel optimumdur.

  • Geriye alternatifin ne olduğu sorusu kalıyor.
    Örneğin “kargo kültü gibi taklit” ve “eski çözümler” diyen birinin sonraki sözü çoğu zaman “kodu metin olarak değil, sözdizimi ağacı olarak düzenleyin” oluyor; ama sorun aynı kalıyor. Sadece “karakter”i “cümle”yle değiştirmek yeterli.
    Bob bir if deyiminin else dalına bir satır eklediyse ve Alice else dalıyla birlikte tüm deyimi sildiyse, akıllı bir sistem ne yapmalı?
  • Otomatik birleştirme meselesini kafa karıştırıcı yazmış olabilirim. Birden çok commit aynı dosyayı değiştirirse Git’in bunları birlikte birleştirmeyi denediğini, ama doğrudan çakışmaların mutlaka gösterilmesi gerektiğini söylemek istemiştim.
    Genel olarak bu yaklaşımın doğru olduğuna katılıyor gibiyim.

• Soruları veya geri bildirimleri alabilirim. Bir iki saat toplantıda olacağım ama bu konular hakkında konuşmayı seviyorum. Buradan ya da e-postayla, hangisi kolaysa gönderebilirsiniz: [e-mail]

  • Çevrimdışı desteği sürdürürseniz sonunda daha ilginç vakalar ortaya çıkacaktır. Örneğin şöyle bir durum: “Uçakta Wi-Fi olmadığı için bunun üzerinde çalışıyordum, sonra gidişatı hoşuma gitmedi; dizüstünü kapatıp kestirdim. Sonraki birkaç gün masaüstünde belge üzerinde çalıştım. Hafta sonu dizüstünde belgeyi açtığımda, uçakta yaptığım tüm değişikliklerin belgeye girdiğini ve her şeyin altüst olduğunu gördüm. Yardım edin, birleştirmek istememiştim!”
    Git, açık onay olmadan yerel değişiklikleri otomatik olarak araya katmaz. bzr de böyle bir şeyi hayal bile etmezdi. Ama Google Docs gibi şeyler bunu seve seve yapıyor.
    Şimdiye kadarki ilerleme harika; erken erişim programının da iyi gitmesini dilerim.
  • Neden sadece patch/diff tabanlı birleştirme benimsenmesin? Çevrimdışı iş birlikli metin düzenlemeyi yalnızca bir UX optimizasyonu sorunu olarak ifade ediyorsanız, bu onlarca yıl önce çözülmüş bir sorun.

• differential sync(https://neil.fraser.name/writing/sync/) uyguladım. Diğerlerini anlamadım ve grugnotes.com uygulamasında bu en basit görünen seçenekti.
  Uygulama epey kaba saba ve tamamen gerçek zamanlı da değil, ama örnekteki birleştirmeyi kimin önce çevrimiçi olduğundan bağımsız olarak düzgün şekilde hallediyor. Silme işlemi önce çevrimiçi gelirse colour sürümü atılıyor ve düzenleme geçmişine de kaydedilmiyor.
  Muhtemelen daha fazla sorun vardır ve ikiden fazla kullanıcı durumunda ne olacağını da bilmiyorum, ama kendi kullanımım için memnunum.