Kontrol versi untuk kolaborasi (dengan perbedaan tingkat kata)?

20

Sebagian besar makalah sekarang ditulis secara kolaboratif, dan kolaborator sering berada di tempat yang berbeda. Saya selalu menggunakan sistem kontrol versi untuk dokumen dan kode saya, dan juga menemukan kontrol versi penting untuk proyek perangkat lunak kolaboratif, tetapi tampaknya banyak peneliti dalam teori menghindari penggunaannya untuk menulis makalah bersama. Untuk meyakinkan kolaborator saya bahwa kontrol versi (kontrol revisi) adalah ide yang baik untuk bekerja bersama, tampaknya ada beberapa prasyarat. Tidak mungkin memaksa semua orang untuk khawatir tentang serangkaian konvensi khusus untuk jeda baris dan paragraf, atau untuk menghindari konversi tab / spasi.

Apakah seseorang menawarkan hosting gratis dari repositori dokumen bersama kecil, dengan kontrol versi ramah dokumen teks yang dapat menangani perbedaan level kata ( bukan berbasis garis)?

Jika tidak, maka saya akan menyambut saran lain yang didasarkan pada pengalaman (tolong hindari spekulasi, silakan).

Saya sedang memikirkan Git, Subversion, Mercurial, darcs, atau Bazaar, yang dibentuk untuk menangani perbedaan level kata dengan wdiff, bersama dengan cara sederhana untuk mengatur akses yang dijamin oleh kunci publik (misalnya melalui ssh). Namun, tidak ada penyedia kontrol versi yang saya lihat tampaknya menawarkan hal seperti ini. Untuk kolaborasi ilmiah, fitur "perusahaan" yang ditekankan oleh banyak dari perusahaan ini tidak terlalu penting (banyak cabang, integrasi dengan trac, audit oleh pihak ketiga, tim proyek hierarkis). Tetapi perbedaan tingkat kata tampaknya kritis namun tidak didukung. Dalam pengalaman saya, dengan perbedaan level baris untuk file teks, setiap orang harus menghindari memformat ulang paragraf dan editor yang mengubah tab menjadi spasi atau sebaliknya menyebabkan masalah; tampaknya juga ada banyak konflik edit palsu.

Lihat pertanyaan terkait di MO tentang alat untuk kolaborasi , dan pertanyaan terkait di TeX.SE, tentang kontrol versi untuk dokumen LaTeX dan LaTeX paket LaTeX untuk kontrol versi . Lihat juga Grafik Tinjauan Perbandingan Hosting SVN untuk daftar besar penyedia hosting, hanya untuk salah satu sistem kontrol versi utama.

Sunting: Jawaban Jukka Suomela untuk pertanyaan TeX.SE "Perangkat LaTeX-sadar terbaik dan menggabungkan untuk subversi " tampaknya menjadi saran terbaik sejauh ini, yang mencakup cara menafsirkan delta pada tingkat kata. Selain itu, Jukka telah menjelaskan bagaimana perbedaan antara versi berturut-turut pada akhir repositori terpisah dari perbedaan tingkat pengguna yang digunakan untuk deteksi konflik dan penggabungan perubahan. Jawaban Jukka di TeX.SE secara eksplisit mengecualikan pengeditan simultan dan penggabungan, sebagai gantinya bergantung pada token edit atom tradisional untuk menghindari konflik edit. Mengklarifikasi (dan memodifikasi) pertanyaan awal saya, apakah ada cara untuk memastikan bahwa konflik edit dapat diselesaikan berdasarkan perbedaan kata, bukan berdasarkan perbedaan baris? Dengan kata lain, bisawdiffatau alat serupa diintegrasikan ke dalam deteksi konflik bagian dari alat kontrol versi, mirip dengan cara perbedaan end-of-line dan perbedaan dalam spasi dapat diabaikan?

soft-question research-practice software writing András Salamon
sumber
3
Saya tidak begitu mengerti pertanyaannya. Misalnya, dalam SVN, perbedaan yang ditampilkan kepada pengguna dihasilkan oleh klien, dan itu tergantung pada klien SVN Anda (dan konfigurasinya) apakah Anda mendapatkan perbedaan berbasis kata atau perbedaan berbasis garis. Perusahaan yang meng-host repositori SVN Anda tidak memengaruhi ini sama sekali.
Jukka Suomela
2
@ suresh Jika Anda mengedit dokumen teks (tertulis), sering kali harus memindai seluruh baris dalam diff untuk melihat bahwa seseorang mengubah satu koma. Perilaku yang benar biasanya adalah menunjukkan unit minimal perubahan. Atau, pertimbangkan perilaku jika seseorang tidak menggunakan jeda baris. Kemudian mengubah satu kata akan menyebabkan seluruh paragraf muncul di diff untuk Anda menemukan perubahan kecil.
Mark Reitblatt
2
Saya tidak menggunakan garis keras untuk membungkus garis. Dalam kode sumber Lateks saya, satu baris teks fisik biasanya satu paragraf penuh teks. Editor dapat membungkus kata untuk ditampilkan, tergantung pada lebar jendela saat ini. Ini menyederhanakan banyak hal; tidak perlu khawatir tentang hal-hal seperti apakah saya harus membungkus ulang sebuah paragraf, atau untuk menyetujui lebar baris "benar" dengan rekan penulis Anda. Namun, Anda akan memerlukan alat tingkat kata berbeda untuk melihat perubahan dengan cepat.
Jukka Suomela
2
@Andras Maksud saya adalah bahwa sistem VC hanya perlu dapat merekonstruksi dua revisi di sisi klien, dan tidak mengherankan semua sistem VC dapat melakukan itu. Apa yang Anda butuhkan adalah utilitas penggabungan tiga arah tingkat kata, tapi saya tidak tahu. (Sebagai contoh, TortoiseMerge dan kdiff3 keduanya berbasis garis.) Setelah Anda memiliki utilitas seperti itu, maka sistem VC yang memungkinkan Anda untuk menentukan utilitas penggabungan eksternal akan cukup. (Itu termasuk svn, bzr, git, hg ...)
Maverick Woo
3
Salah satu sumber kebingungan di sini adalah bahwa ada built-in algoritma biner (yang beroperasi pada tingkat byte individu) yang digunakan oleh SVN dalam komunikasi antara server dan klien, dan juga secara internal oleh server untuk menjaga repositori padat. Ini hanyalah sebuah optimasi; itu tidak terlihat oleh pengguna dan algoritma beda biner yang sama dapat diterapkan untuk semua jenis file. Semua hal yang terlihat oleh pengguna (perbedaan yang dapat dibaca manusia, penggabungan, resolusi konflik ...) terjadi di sisi klien.
Jukka Suomela

Jawaban:

11

Saya telah menggunakan git untuk berkolaborasi pada beberapa dokumen yang ditulis dalam lateks. Anda harus mematuhi beberapa aturan:

  • Mulai setiap kalimat pada baris baru, lateks mengabaikan baris baru ini selama tidak ada baris kosong
  • Gunakan konfigurasi yang sama untuk memformat (tab / spasi / lebar teks maks)
  • Untuk hasil terbaik, buat file .gitattributes di repositori Anda dan tambahkan baris *.tex diff=tex. Ini membuat sintaks tex berbeda dan mengarah ke output yang lebih bermakna.

Anda kemudian dapat menggunakan git diff --color-wordsdan gitk --color-wordsuntuk melihat perbedaan kata (juga lihat artikel ini Perbedaan kata per kata di Git tentang cara mengkonfigurasi git untuk selalu menggunakan algoritme kata-beda untuk menampilkan log git diff / git).

Untuk mengurangi penggabungan manual, saya dapat merekomendasikan menggunakan file terpisah untuk bagian dan subbagian (tergantung pada ukuran dokumen Anda).

Davy Landman
sumber
Saya akan mempertimbangkan melakukan ini untuk dokumen saya sendiri, sepertinya ini cara mudah untuk mencapai sebagian besar tujuan saya. Tetapi tidak semua orang ingin bekerja dengan cara ini ...
András Salamon
2
Bagi orang yang ragu-ragu untuk bekerja dengan cara ini, Anda dapat menggunakan TortoiseGit jika mereka tidak menyukai baris perintah git. Jika ini tentang setiap kalimat pada bagian baris baru, dan selama tidak ada lebar teks maksimum yang dipaksakan, ini tidak penting. (Saya telah mengerjakan beberapa proyek tanpa aturan itu)
Davy Landman
Secara keseluruhan, saya setuju bahwa git adalah pilihan yang baik. Tetapi mengapa bisa memisahkan file untuk (sub) bagian mengurangi jumlah penggabungan manual? Saya juga bertanya-tanya bagaimana membantu setiap kalimat pada baris baru (terkadang kalimat bercampur dalam proses pengeditan).
dd1
berkenaan dengan memisahkan file: pada saat itu, saya tidak mengerti detail yang tepat dari penggabungan git, sehingga sebenarnya tidak dibutuhkan, tetapi masih disarankan karena alasan lain. Kalimat pada baris baru sangat penting, karena sebagian besar alat di sekitar git selalu menunjukkan perubahan garis, jika Anda kemudian menggunakan strategi lain, katakan biarkan editor melakukan linebreak, setiap kali seseorang mengubah 1 kata dalam satu paragraf, Anda harus berburu jika itu terjadi, dan dalam kasus penggabungan otomatis: tidak mungkin.
Davy Landman
4

Saya benar-benar ingin menggemakan orang lain dan menyarankan agar Anda duduk dan menyusun strategi SVN yang bagus. Saya menggunakan SVN untuk menampung seluruh struktur "penelitian" saya:

  • Pengelolaan referensi JabRef
  • PDF yang diunduh
  • Artikel

Ini hebat karena mengandung segalanya, dan tentu saja memberikan sejarah. Peringatannya adalah Anda membutuhkan server Anda sendiri. Tetapi jika Anda memiliki beberapa mesin Windows yang ada (atau apa pun yang Anda sukai), Anda dapat menginstalnya hanya melalui VisualSVN Server . Anda kemudian membuat akun yang sesuai untuk kolaborator, dan memberi mereka akses ke area yang sesuai (misalnya, mungkin akses baca ke file bibtex JabRef Anda, dan baca / tulis ke area artikel 'dalam proses' yang dibagikan).

TortiseSVN dapat digunakan sebagai klien Windows untuk berinteraksi dengan SVN. Anda perlu berhati-hati memindahkan / menghapus file dan menyalin folder (SVN akan menyimpan metadata di dalam folder tersembunyi di setiap folder Anda, jadi Anda harus menjalankan perintah delete dari dalam SVN untuk menyingkirkannya, perlu sedikit membiasakan diri. untuk, tetapi bernilai investasi).

Kemudian, ketika bekerja dengan kolaborator, mereka jelas juga harus menggunakan SVN. Tetapi, sekali lagi, investasi dalam pembelajaran tidak sia-sia. Dan melalui beberapa pemikiran, Anda juga dapat memilikinya sehingga Anda memiliki akses hanya baca ke file jabref mereka (mungkin melalui fasilitas 'eksternal' di svn).

Dengan cara ini, dengan sedikit pemikiran dan sedikit usaha, Anda bisa berada dalam situasi di mana Anda mengedit dokumen seperti biasa, melakukan perubahan setiap malam, memperbarui di pagi hari dan menyelesaikan semua konflik dengan mudah.

Saya sangat merekomendasikannya. Semakin banyak orang yang membuat SVN mereka sendiri semakin baik, karena hanya akan meningkatkan opsi kolaborasi di masa depan (meskipun, tentu saja, akan bermanfaat jika mungkin ada cara 'standar' untuk mengatur repositori ilmiah).

- Sunting: Infact, saya telah menulis proposal seperti ini di sini: Strategi untuk Kerja Sama Ilmiah dengan LaTeX dan SVN . Ini mengusulkan untuk menggunakan fitur svn eksternal untuk memungkinkan kolaborasi yang mudah antara orang-orang dengan pengaturan yang sama. Beri tahu saya jika perlu diubah atau tidak tepat.

Sutra Siang
sumber
4

Sambil membaca posting hebat Anda dan mencari solusi sendiri, saya menemukan pilihan untuk mewarnai perubahan pada level kata di gitk . Parameter gitk tampaknya merupakan fitur baru dan / atau tidak berdokumen karena pelengkapan otomatis tidak menawarkannya dan halaman manual gitk tidak mencantumkannya.
Berikut adalah opsi yang saya temukan:

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

Anda dapat menemukan beberapa diskusi tentang topik itu mencari gitk "diff --color-words" .

Sunting:
Ini seperti apa ...

Perbedaan diwarnai pada tingkat kata menggunakan gitk

JJD
sumber
1

Saya mengerti masalahnya dengan sangat baik. Saya sudah mulai menggunakan Kaleidoscope untuk diff dengan git. Ini hanya untuk Mac tetapi perbandingannya berfungsi lebih baik daripada wdiff, dan juga memiliki antarmuka dan pembaruan langsung.


sumber
2
Bagi saya tampaknya Kaleidoscope hanyalah alat diff berbasis garis yang juga menyoroti perubahan di dalam setiap baris. Ini bukan pengganti untuk wdiff dan teman-teman. Kaleidoskop menghasilkan diff yang tidak dapat dibaca jika Anda, misalnya, hanya mengambil paragraf teks dan mengubah beberapa jeda baris. Alat berbasis Wdiff mengabaikan perubahan jeda baris.
Jukka Suomela