Alat kolaboratif untuk boneka / profesor

Misalkan rekan penulis dari dua atau lebih lembaga berbeda sedang menulis makalah dalam lateks, dan ingin melakukan yang lebih baik daripada berulang kali mengirim email konsep bolak-balik.

Mereka menyadari bahwa mereka dapat membuka secara gratis akun dropbox, membagikan kata sandi, dan menyinkronkan versi kertas di komputer mereka dengan yang ada di dropbox. Namun, jika dua orang secara bersamaan mengedit bagian yang sama, mereka akan saling menimpa perubahan lainnya.

Mereka juga telah mendengar bahwa sistem kontrol versi seperti SVN dan Git memiliki alat untuk menggabungkan perubahan bersamaan, yang bekerja dengan cukup baik. Dokumentasi produk-produk ini agak sulit dibaca, dan lebih terfokus pada cara membatalkan perubahan dan bagaimana mengelola "cabang" yang berbeda daripada pada kebutuhan dasar penulis bersama menulis makalah.

Apakah ada penjelasan langkah demi langkah sederhana tentang cara menggunakan sistem kontrol versi dalam pengaturan ini:

• repositori pusat
• salinan lokal
• "pintar" bergabung
• tidak ada cabang

?

Dari sistem kontrol versi standar, mana yang paling mudah digunakan? (Kami berbicara profesor ilmu komputer teoretis di sini.)

Apakah ada alat yang lebih sederhana yang hanya melakukan sinkronisasi dengan penggabungan pintar, tanpa kontrol versi?

Sebaliknya, apakah orang-orang yang menggunakan sistem kontrol versi untuk menulis makalah dengan tulisan tunggal benar-benar merasa bahwa kemampuan tak terbatas-undo bernilai kompleksitas tambahan?

Pertama: Jika Anda tertarik pada pengeditan kolaboratif waktu-nyata, coba sesuatu seperti gobby . Ini memungkinkan Anda mengedit dokumen secara bersamaan.

Sedangkan untuk sistem revisi, saya hanya terbiasa dengan SVN. Ini yang Anda lakukan, setelah menginstal subversi, tentu saja:

1. Dapatkan seseorang untuk membuat Anda repositori dan memberikan URL, nama pengguna, dan kata sandi
2. Pergi ke tempat Anda ingin memiliki salinan lokal Anda
3. Dalam sebuah shell (command line?), Ketik: svn co url://to.your/repository(check-out). Sekarang folder baru dengan konten repositori muncul.

Itu saja. Sekarang perintah paling dasar:

• Setiap kali Anda menambahkan file baru foo, masukkan:svn add foo
• Setiap kali Anda ingin menghapus file, masukkan: svn rm foo
• Setiap kali Anda melakukan perubahan, masukkan: svn ci(check-in)
• Kapan pun Anda ingin mendapatkan barang terbaru, masukkan: svn up(perbarui)

Ada juga perintah untuk memindahkan, menyalin, bercabang, menyelesaikan konflik, ... tetapi selama Anda tidak mencoba hal-hal lucu, Anda baik-baik saja dengan yang di atas. Jika ada yang rusak atau sepertinya, backup hasil edit Anda, hapus seluruh folder dan periksa kembali semuanya. Itu untuk svn seperti me-reboot untuk Windows.

Tambahan: Saya melihat Anda tampaknya khawatir tentang "penggabungan pintar". Saya berasumsi bahwa Anda merujuk harus versi yang berbeda dari file yang digabungkan, dengan asumsi bahwa dua orang menambahkan hal-hal di bagian kertas yang terpisah. Sejauh yang saya tahu, svn akan memperlakukan itu sebagai konflik, dan mungkin memang demikian. Saya tidak berpikir bahwa ada prosedur umum yang memastikan Anda mendapatkan apa yang Anda inginkan setelah dua orang memanipulasi sumber yang sama. Ada klien svn grafis yang memvisualisasikan konflik tersebut dan membantu Anda menyelesaikannya; mereka cukup banyak pemirsa berbeda jika Anda dapat memilih versi mana yang harus disimpan untuk setiap baris yang bertentangan). Ini akan membutuhkan pekerjaan.

Saya perhatikan bahwa tidak ada yang memberikan tutorial "kecil" untuk GIT , jadi saya akan mencoba untuk membahasnya. GIT lebih cepat dan lebih baik dari SVN, tetapi mungkin lebih mudah bagi Anda untuk mendapatkan akun SVN di server di universitas Anda, karena SVN sudah mapan. Kolaborator Anda juga mungkin tahu cara menggunakannya.

Bahkan jika Anda berkolaborasi menggunakan SVN, Anda mungkin ingin menggunakan GIT untuk versi lokal Anda sendiri (Iya!).

Peringatan pertama : GIT sangat kuat dan untuk penggunaan dasar hanya sedikit lebih sulit untuk digunakan daripada SVN (misalnya, satu opsi yang akan ditambahkan di baris perintah; dua langkah komit untuk repositori pusat).

Peringatan kedua : GIT memiliki filosofi mempertimbangkan sekumpulan perubahan sebagai atom (a sebagaimana mereka menyebutnya) bahkan jika set tersebut merentang beberapa file. Juga di GIT Anda memiliki gagasan repositori lokal dan repositori pusat . BAIK : Anda dapat bekerja secara offline. BURUK : Anda perlu dua langkah komit ke server pusat .$\Delta$

Perintah dasar dengan asumsi Anda sudah memiliki repositori

• Kloning repositori: git clone <url>
• Perbarui repositori lokal Anda: git pull <repo>atau hanya git pulljika Anda kloning seperti di atas.
• Perintah tarik benar-benar melakukan keduanya git fetchdan git merge. Mantan "mengambil" barang-barang dari server pusat, dan yang kedua menerapkan gabungan file Anda dan yang dari server.

Penggabungan otomatis selama tidak ada pengeditan simultan pada bagian yang sama dari beberapa file. Jika penggabungan gagal Anda direktori kerja tetap dalam "keadaan penggabungan", yang berarti bahwa Anda harus memperbaiki konflik dan kemudian Anda harus melakukan salinan gabungan. Jika Anda masih memiliki konflik yang tidak dikelola dalam file Anda maka komit akan gagal lagi, tidak ada sampah yang dilakukan.

• Menambahkan file baru yang akan dilakukan: git add <file name>.
• Komit perubahan ke repositori lokal Anda : git commit -am "<textmessages>"atau git commit -ajika Anda ingin mengedit pesan komit.
• Dorong perubahan di repositori lokal Anda ke repositori pusat .

Perhatikan bahwa untuk mendorong perubahan ke repositori pusat Anda, Anda harus terlebih dahulu berkomitmen pada repositori lokal Anda dan Anda harus mendorong semua komit (bahkan lebih dari satu) ke repositori pusat Anda .

Buat repositori pengguna-lokal

• Pembuatan repositori git initdi folder apa pun yang Anda suka.
• Selesai!

Buat repo bersama-publik (juga pribadi jika Anda membayar tunai) dengan GUI yang bagus.

• Gunakan GitHub

Buat sebanyak mungkin repositori pribadi / publik dengan grup pengguna yang berbeda tetapi tidak ada GUI.

• Mintalah akun SSH tanpa kata sandi di mesin yang dapat diakses.
• Jangan khawatir karena otentikasi dilakukan oleh kunci SSH.
• Instal Gitosis sesuai dengan tutorial ini .
• Sekarang Anda dapat mengadministrasi git server Anda sendiri dengan mengedit satu file dan mengirimkannya ke repositori!

Git tidak memerlukan server pusat : folder apa pun di komputer Anda dapat digunakan sebagai repositori, sehingga Anda dapat bermain dengan git dan membuat pengujian Anda offline. Anda dapat menginisialisasi satu repositori dan mensimulasikan tiga kolaborator di tiga folder lain tanpa mengirim sedikit pun di internet. Ini karena setiap salinan repositori yang dikloning adalah repositori berfitur lengkap yang dapat Anda komit. Ini bagus jika Anda ingin bekerja dalam penerbangan antara AS, Cina, atau Eropa.

Google Documents ( https://docs.google.com ) menyediakan alat yang hebat untuk membuat dokumen bersama (termasuk pengeditan waktu nyata). Ini menyimpan semuanya secara online untuk Anda dan terintegrasi dengan baik dengan akun Gmail Anda. Secara default Google Documents tidak memiliki kompatibilitas LaTeX, tetapi Anda dapat mengaktifkannya dengan masuk ke sini:

http://docs.latexlab.org/

Saya tidak yakin seberapa baik kerjanya untuk rollback, tapi saya yakin ada fitur untuk itu. Saya telah mendengar beberapa orang menggunakan plug-in LaTeX Google Wave untuk mengerjakan sketsa awal untuk makalah.

Saya membuat rekan penulis saya belajar Mercurial, dan saya dulu membuat mereka belajar Subversion. Jika Anda adalah penggemar Subversion, baca saja ini , itu semua benar.

Tidak masalah sistem apa yang Anda gunakan, sejauh ini hal yang paling sulit adalah membuat orang lain menginstal perangkat lunak dan mulai menggunakannya. Skype adalah solusi sempurna. Versi terbaru Skype memungkinkan "desktop sharing" yang sangat membantu ketika Anda ingin memimpin rekan penulis melalui prosedur instalasi. Dan saya telah menggunakan berbagi desktop langsung yang dikombinasikan dengan Skype untuk menulis makalah dengan rekan penulis saya. Ini bekerja dengan cukup baik.

Yang benar-benar dibutuhkan adalah "Github for ilmuwan". Sesuatu yang memberikan repositori, memiliki kontrol versi, pengeditan kolaboratif, dll. Coba tebak, ada http://www.scribtex.com/ .

di sini adalah editor Lateks online kolaboratif baru yang disebut WriteLatex yang terlihat menjanjikan, sebagai toko serba ada yang dekat untuk banyak kebutuhan / persyaratan penulisan ilmiah.

• berfungsi di ponsel
• memiliki pratinjau waktu-nyata
• berbagi mudah / pribadi
• menemukan kesalahan lateks
• memungkinkan penambahan pada pustaka / gaya lateks
• penyimpanan awan

penulis pendamping John Hammersley memposting pengumuman di tcs se meta di sini dan dia responsif terhadap umpan balik (5 suara lebih banyak pada iklan & akan muncul di situs utama). sepertinya bisa berkembang menjadi alat yang berharga untuk komunitas tcs dari waktu ke waktu dan mungkin penulis akan dapat mengimplementasikan beberapa fitur populer secara khusus berdasarkan permintaan.

Bagaimana dengan sistem sederhana, solusinya:

• Google Documents, penulis Zoho ... dan alat kolaboratif lainnya.
• Dropbox menangani situasi ketika dua orang mencoba melakukan perubahan pada file yang sama. Orang yang berkomitmen kedua mendapatkan / mengganti namanya file (X.txt -> X.txt_blabla ...), dan file asli (X.txt) up-to-date dengan versi terbaru. Info lebih lanjut tentang: Bantuan Dropbox: "Apa yang terjadi jika dua orang mengubah file yang sama?"

Itu keluar dari pertanyaan, tetapi kadang-kadang ada situasi di mana bagian dari kelompok mampu solusi sederhana seperti SVN, sedangkan bagian lain dari kelompok mampu kontrol versi terdistribusi seperti GIT. Dalam situasi seperti itu kerjasama dimungkinkan:

• git-svn - Operasi dua arah antara repositori Subversion dan git
• Git - SVN Crash Course
• Secara Efektif Menggunakan Git Dengan Subversi

Saya baru-baru ini menemukan sharelatex.com dan menggunakannya dengan kolaborator saya untuk ikut menulis makalah. Saya sangat menyukainya sehingga rencana saya saat ini adalah menggunakannya untuk semua proyek saya. Beberapa fitur penting:

• TeXing dalam-browser real-time (seperti Google Docs, tetapi dibuat untuk TeX, highlight-syntax dan semuanya).

• Kompilasi dalam browser dan melihat PDF

• Mendukung proyek dengan banyak file

• Memiliki fitur riwayat

• Sinkronisasi dengan Dropbox (akan segera dirilis secara publik, dari status beta saat ini). Dengan cara ini Anda dapat membongkar penyimpanan cadangan dll. Ke Dropbox. Bergantung pada bagaimana hal itu dilakukan, ini juga harus memungkinkan Anda menggunakan sharelatex bahkan jika rekan penulis Anda tidak mau, selama mereka bersedia menggunakan Dropbox untuk berbagi file.

• Anda dapat mengunduh / mengunggah proyek Anda kapan saja, sehingga Anda tidak terjebak menggunakan sharelatex jika terjadi kesalahan atau Anda berubah pikiran atau apa pun.

Satu-satunya downside (tapi saya pikir itu layak): walaupun menggunakan sharelatex gratis, beberapa fitur-fiturnya tidak. Khususnya, untuk menggunakan sinkronisasi Dropbox (ketika mereka merilisnya), atau jika Anda ingin lebih dari 6 penulis bersama untuk bekerja pada proyek sharelatex yang sama, Anda harus membayar $ 8 / bulan. atau $ 80 / tahun [per April 2013]. Begitu mereka merilis sinkronisasi Dropbox, sepertinya harga yang sangat adil bagi saya.

[Penafian: Saya tidak memiliki hubungan dengan sharelatex atau karyawannya selain saya menggunakan produk mereka.]

SVN adalah alat yang dikembangkan untuk tujuan ini. Saya akan berupaya untuk mempelajarinya. Ini tidak lebih rumit daripada belajar menggunakan katakanlah paket Latex algorithm2e atau salah satu paket Latex pencipta slide pdf.

Karena itu, saya menggunakan CVS bukan SVN. Ada dukungan yang lebih baik dari admin CS di lembaga kami (server SVN lebih dikelola oleh pengguna). Plus, saya menghargai bahwa file versi yang mendasarinya masih ada dan dapat diedit jika ada yang sangat-sangat salah.

Ada 2 kelemahan jika dibandingkan dengan SVN. Ganti nama file tidak sebaik, tapi saya bisa hidup dengan itu (pilih nama baik pertama kali). Masalah kedua adalah bahwa seseorang membutuhkan akun CS lokal untuk mengakses repositori. Karena itu, dari lembaga lain, akses hanya dimungkinkan jika akun dibuat terlebih dahulu. Tentu saja saya tidak berharap ini menjadi masalah nyata di mana saja; anggota departemen lokal mungkin dapat mensponsori akun itu.

Pembatasan akses lokal disebabkan oleh kenyataan bahwa admin tidak ingin mendukung server. (Lebih sulit untuk mengamankan dll.)