İşbirliği için sürüm kontrolü (kelime düzeyinde farklarla)?


20

Çoğu makale artık birlikte yazılıyor ve ortak çalışanlar genellikle farklı yerlerde bulunuyor. Belgelerim ve kodum için her zaman sürüm kontrol sistemlerini kullandım ve aynı zamanda işbirlikçi yazılım projeleri için sürüm kontrolünü kritik buldum, ancak teoride birçok araştırmacı ortak makaleler yazmak için kullanımlarından kaçınıyor gibi görünüyor. Ortak çalışanlarımı sürüm kontrolünün (revizyon kontrolü) birlikte çalışmak için iyi bir fikir olduğuna ikna etmek için bazı önkoşullar var gibi görünüyor. Herkesi satır sonları ve paragraflar için belirli bir dizi sözleşme hakkında endişelenmeye veya sekme / boşluk dönüşümlerinden kaçınmaya zorlamak mümkün değildir.

Birisi, kelime düzeyi farklarını ( satır tabanlı değil ) işleyebilen metin belgesi dostu sürüm kontrolü ile küçük paylaşılan belge havuzlarının ücretsiz olarak barındırılmasını sağlıyor mu?

Değilse, o zaman deneyime dayanan diğer önerileri memnuniyetle karşılarım (spekülasyondan kaçınalım, lütfen).

Wdiff ile kelime düzeyinde farklılıkları ele almak için ayarlanmış Git, Subversion, Mercurial, darcs veya Bazaar'ı, genel anahtarlarla (örneğin ssh aracılığıyla) güvenli bir şekilde erişmenin basit bir yolunu düşünmüştüm. Ancak, baktığım sürüm kontrol sağlayıcılarının hiçbiri böyle bir şey sunmuyor gibi görünüyor. Bilimsel işbirliği için, bu şirketlerin birçoğunun vurguladığı "kurumsal" özellikler çok önemli değildir (çok sayıda şube, trac ile entegrasyon, üçüncü taraflarca denetim, hiyerarşik proje ekipleri). Ancak kelime seviyesi farkları kritik ve desteksiz görünüyor. Deneyimlerime göre, metin dosyaları için satır düzeyi farklılıklarıyla, herkes sekmeleri boşluklara değiştiren paragrafları ve editörleri yeniden biçimlendirmekten kaçınmak zorundadır; birçok sahte düzenleme çatışması var gibi görünüyor.

İşbirliği araçları hakkında MO'daki ilgili soruya ve TeX.SE'de LaTeX belgeleri için sürüm kontrolü ve sürüm kontrolü için LaTeX paketleri hakkında ilgili sorulara bakın . Ana sürüm kontrol sistemlerinden sadece biri için, barındırma sağlayıcılarının geniş bir listesi için SVN Hosting Karşılaştırma İnceleme Grafiğine de bakın .


Düzenleme: Jukka Suomela'nın TeX.SE sorusuna cevabı " En iyi LaTeX bilinçli fark ve yıkım için birleştirme araçları ", bir kelime düzeyinde deltas yorumlamak için nasıl kapsayan şimdiye kadar en iyi öneri gibi görünüyor. Dahası, Jukka, depo tarafındaki birbirini izleyen sürümler arasındaki farkların, çakışma tespiti ve değişikliklerin birleştirilmesi için kullanılan kullanıcı düzeyi farklarından nasıl ayrı olduğunu açıklamıştır. Jukka'nın TeX.SE'deki cevabı, eşzamanlı düzenlemeleri ve birleştirmeyi açıkça dışlıyor ve bunun yerine düzenleme çakışmalarını önlemek için geleneksel atomik düzenleme jetonuna güveniyor. Orijinal sorumu netleştirmek (ve değiştirmek), düzenleme çakışmalarının satır farkı temelinde değil, kelime farkı temelinde çözülmesini sağlamanın bir yolu var mı? Başka bir deyişle,wdiffveya benzer araçlar , satır sonu farklarının ve boşluktaki farklılıkların göz ardı edilme şekline benzer şekilde, sürüm kontrol araçlarının çakışma algılama kısmına entegre edilebilir mi?


3
Soruyu tam olarak anlamıyorum. Örneğin, SVN'de, bir kullanıcıya görüntülenen farklar istemci tarafından oluşturulur ve kelime tabanlı farklar veya satır tabanlı farklar alıp almadığınız SVN istemcinize (ve yapılandırmasına) bağlıdır. SVN deponuzu barındıran şirket bunu hiç etkilemez.
Jukka Suomela

2
@suresh Metin belgelerini düzenliyorsanız (yazıyorsanız), birisinin bir virgül değiştirdiğini görmek için bir farkın tamamını bir satırda taramak genellikle bir acıdır. Doğru davranış genellikle minimum değişim birimini göstermektir. Veya, birisi satır sonları kullanmıyorsa davranışı düşünün. Daha sonra tek bir kelimeyi değiştirmek, tüm paragrafın küçük değişikliği bulmanız için farkta görünmesine neden olur.
Mark Reitblatt

2
Çizgileri sarmak için sert satır sonları kullanmıyorum. Lateks kaynak kodumda, fiziksel bir metin satırı genellikle metnin tam bir paragrafıdır. Düzenleyici, geçerli pencere genişliğine bağlı olarak, görüntüleme için word-wrap yapabilir. İşleri çok basitleştirir; bir paragrafı yeniden sözcük olarak sarmam veya ortak yazarlarınızla "doğru" çizgi genişliği konusunda anlaşmaya varmam gibi şeyler hakkında endişelenmenize gerek yoktur. Ancak, değişiklikleri hızlı bir şekilde görmek için kelime düzeyinde bir fark aracına ihtiyacınız olacaktır.
Jukka Suomela

2
@Andras Demek istediğim, VC sisteminin sadece istemci tarafında iki revizyonu yeniden yapabilmesi gerektiğiydi ve şaşırtıcı bir şekilde tüm VC sistemleri bunu yapamazdı. İhtiyacınız olan şey, kelime düzeyinde üç yönlü birleştirme yardımcı programıdır, ancak bilmiyorum. (Örneğin, TortoiseMerge ve kdiff3'ün her ikisi de satır tabanlıdır.) Böyle bir yardımcı programa sahip olduğunuzda, harici bir birleştirme yardımcı programı belirtmenize izin veren herhangi bir VC sistemi yeterli olacaktır. (Bu svn, bzr, git, hg ... içerir)
Maverick Woo

3
Buradaki bir karışıklık kaynağı, sunucu ve istemci arasındaki iletişimde SVN tarafından ve ayrıca depo tarafından saklamak için sunucu tarafından dahili olarak kullanılan yerleşik bir ikili fark algoritmasının (bireysel bayt düzeyinde çalışan) olmasıdır. kompakt. Bu sadece bir optimizasyon; kullanıcı tarafından görülemez ve aynı ikili fark algoritması herhangi bir dosya türüne uygulanabilir. Kullanıcı tarafından görülebilir tüm şeyler (insan tarafından okunabilen farklar, birleştirme, çakışma çözümü ...) istemci tarafında olur.
Jukka Suomela

Yanıtlar:


11

Lateks ile yazılmış bazı belgeler üzerinde işbirliği yapmak için git'i kullandım. Bazı kurallara uymanız gerekir:

  • Her cümleyi yeni bir satırda başlat, lateks boş satır olmadığı sürece bu satırları yok sayar
  • Biçimlendirme için aynı yapılandırmayı kullanın (sekme / boşluklar / maks. Metin genişliği)
  • En iyi sonuçlar için deponuzda bir .gitattributes dosyası oluşturun ve satırı ekleyin *.tex diff=tex. Bu, tex sözdizimi konusunda fark yaratır ve daha anlamlı çıktıya yol açar.

Daha sonra git diff --color-wordsve gitk --color-wordssözcük farklılıklarını görmek için kullanabilirsiniz (ayrıca git'i git fark / git günlüğünü görüntülemek için word-diff algoritmasını kullanmak üzere nasıl yapılandıracağına ilişkin Git'teki sözcük sözcük farkları makalesine bakın ).

Manuel birleştirmeleri azaltmak için bölümler ve alt bölümler için ayrı dosyalar kullanmanızı tavsiye edebilirim (belgenizin boyutuna bağlı olarak).


Bunu kendi belgelerim için yapmayı düşüneceğim, hedeflerimin çoğuna ulaşmak için kolay bir yol gibi görünüyor. Ama herkes bu şekilde çalışmaya hevesli değil ...
András Salamon

2
Bu şekilde çalışmak isteyenler için, git komut satırını beğenmedikleri takdirde TortoiseGit'i kullanabilirsiniz. Zorunlu maksimum metin genişliği olmadığı sürece, yeni bir satır kısmındaki her bir cümle hakkındaysa, bu o kadar da önemli değildir. (Bu kural olmadan bazı projelerde çalıştım)
Davy Landman

Genel olarak, git'in iyi bir seçim olduğunu kabul ediyorum. Peki (alt) bölümler için ayrı dosyalar neden manuel birleştirme sayısını azaltabilir? Ayrıca her cümlenin yeni bir satırda başlatılmasının nasıl yardımcı olabileceğini merak ediyorum (bazen cümle düzenleme sürecinde karışıyor).
dd1

ayırma dosyaları ile ilgili: o zaman, git birleştirmenin kesin ayrıntılarını anlamadım, bu yüzden aslında gereksizdir, ancak yine de başka nedenlerle tavsiye edilir. Yeni bir satırdaki cümle çok önemlidir, çünkü git etrafındaki çoğu araç her zaman satır değişiklikleri gösterir, daha sonra başka bir strateji kullanırsanız, editörün satır aralıkları yapmasına izin verin, birisi bir paragrafta 1 kelimeyi her değiştirdiğinde, oldu ve otomatik birleştirme durumunda: hiçbir şekilde.
Davy Landman


4

Gerçekten başkalarını yankılamak ve oturup güzel bir SVN stratejisi geliştirmenizi öneririm. Tüm "araştırma" yapımı barındırmak için SVN kullanıyorum:

  • JabRef referans yönetimi
  • İndirilen PDF'ler
  • Makaleler

Harika çünkü her şeyi içeriyor ve elbette bir tarih sağlıyor. Uyarı kendi sunucunuza ihtiyaç var. Ancak mevcut bir Windows makineniz varsa (ya da rahatınız ne olursa olsun), sadece VisualSVN Server üzerinden kurabilirsiniz . Daha sonra ortak çalışanlar için uygun hesaplar oluşturur ve onlara uygun bir alana erişim izni verirsiniz (örneğin, JabRef bibtex dosyanıza okuma erişimi ve paylaşılan 'devam eden' makale alanına okuma / yazma).

TortiseSVN , SVN ile etkileşim için Windows istemcisi olarak kullanılabilir. Dosyaları taşıma / silme ve klasörleri kopyalama konusunda dikkatli olmanız gerekir (SVN, meta verileri klasörlerinizin her birinde gizli klasörlerin içine kaydeder, bu nedenle kurtulmak için SVN içinden silme komutunu yürütmeniz gerekir, biraz kullanmanız gerekir ancak yatırıma değer).

Daha sonra, bir ortak çalışanla çalışırken, açıkça SVN kullanmaları gerekir. Ancak, yine, öğrenmeye yapılan yatırım değersiz değildir. Bazı düşünceler sayesinde, jabref dosyalarına (belki de svn'deki 'harici' tesis aracılığıyla) salt okunur erişime sahip olmanızı da sağlayabilirsiniz.

Bu şekilde, biraz düşünce ve biraz çaba ile, belgeleri normal şekilde düzenlediğiniz, her gece değişiklikleri gerçekleştirdiğiniz, sabah güncellediğiniz ve tüm çatışmaları kolayca çözebileceğiniz bir durumda olabilirsiniz.

Gerçekten tavsiye ederim. Kendi SVN'lerini ne kadar çok kişi kurarsa, gelecekte yalnızca işbirliği seçeneklerini geliştireceğinden daha iyi olur (tabii ki bilimsel bir havuz kurmanın belki de 'standart' bir yolu olsa da yararlı olacaktır).

- Edit: Infact, burada böyle bir teklif yazdım: LaTeX ve SVN ile Bilimsel İşbirliği Stratejisi . Benzer bir düzene sahip insanlar arasında kolay işbirliği sağlamak için svn externals özelliğinden yararlanmayı önerir . Değişime ihtiyacı olup olmadığını veya sadece uygun olmadığını bana bildirin.


4

Harika yazınızı okurken ve kendime bir çözüm ararken , gitk'te kelime düzeyinde değişiklikleri renklendirme seçeneğine rastladım . Otomatik tamamlama bunu sunmadığından ve gitk man sayfası listelemediğinden gitk parametresi yeni ve / veya belgesiz bir özellik gibi görünüyor .
Bulduğum seçenekler şunlardır:

gitk --word-diff=plain
gitk --word-diff=porcelain
gitk --word-diff=color

Bu konuda "diff --color-words" gitk araması için birkaç tartışma bulabilirsiniz .

Edit:
Bu böyle görünüyor ...

Gitk kullanarak sözcük düzeyinde renklendirilen farklar


1

Sorunu çok iyi anlıyorum. Git ile diffs için Kaleidoscope kullanmaya başladım . Sadece Mac'tir, ancak karşılaştırmaları wdiff'ten daha iyi çalışır ve ayrıca bir arayüzü ve canlı güncellemeleri vardır.


2
Bana göre, Kaleydoskop, sadece her bir çizginin içindeki değişiklikleri vurgulayan çizgi tabanlı bir fark aracı gibi görünüyor. Wdiff ve arkadaşlar için bir yedek değildir. Kaleydoskop, örneğin bir metin paragrafı alır ve satır sonlarını değiştirirseniz okunamayan farklar üretir. Wdiff tabanlı araçlar satır sonlarındaki değişiklikleri göz ardı eder.
Jukka Suomela
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.