Kontrol Versi berdasarkan penyimpanan portabel?


9

Saya mengembangkan proyek pribadi pada dua mesin tanpa menggunakan server bersama atau koneksi jaringan di antara keduanya.

Apakah ada sistem kontrol versi umum yang secara andal mendukung penggunaan penyimpanan portabel (seperti perangkat flash USB) sebagai repositori bersama?


Mengapa Anda ingin / perlu menggunakan penyimpanan portabel?
Bernard

Untuk memindahkan kode antara dua mesin dengan cara yang sama seperti yang dilakukan oleh sistem kontrol versi normal dengan server bersama. (Saya tidak punya server bersama.)
billpg

Saya dulu menggunakan satu set repositori lincah pada USB flash drive untuk memperbarui alat-alat manufaktur di pabrik dan itu bekerja dengan sangat baik. Anda bahkan bisa melihat ketika teknisi di situs telah memodifikasi kode pada mesin lokal, saat Anda pergi, dan menggabungkan (atau menolak) perubahan mereka sebelum menyinkronkan perubahan mereka kembali ke flash drive.
Mark Booth

Sudah dikatakan di sini bahwa SVN mendukung penyimpanan lokal dan Anda dapat menggunakan usb. Tapi saya lebih suka menyimpan DB itu di folder DropBox pribadi saya;) Anda juga dapat menggunakan banyak layanan gratis (seperti assembla atau tfs.visualstudio.com)
Pavel Voronin

Jawaban:


31

Gunakan DVCS seperti Git atau Mercurial .

Sistem kontrol versi terdistribusi tidak memiliki server pusat bersama.

Dengan DVCS, setiap salinan repositori menyimpan sejarah lengkap - semuanya. Ini berarti, bahwa ketika digunakan pada kunci USB setiap perubahan yang Anda lakukan adalah membuat ke repositori pada kunci USB dan ketika dipindahkan di antara komputer akan menyimpan sejarah ini.


9
Dan jika Anda menggunakan github, Anda bahkan tidak perlu membawa drive USB
CamelBlues

Terima kasih. Apakah bisa diatur untuk menggunakan penyimpanan portabel sebagai repositori?
billpg

@ billpg - Ya. Itu hanya hidup dalam struktur direktori.
Oded

@CamelBlues atau bitbucket atau kilnhg atau mungkin berbagai lainnya yang mungkin atau mungkin tidak sesuai ...
Murph

3
Saya punya repositori Mercurial pribadi utama saya di DropBox. Bekerja dengan baik, dan secara otomatis mengimplementasikan cadangan (karena DropBox tidak mungkin hilang pada saat yang sama ketika saya kehilangan semua komputer saya).
David Thornley

7

Terlepas dari GIT, Mercurial dll yang disarankan di atas, juga melihat pada Fosil - Ini memiliki keuntungan bahwa biner waktu menjalankan kecil (1Meg atau lebih untuk Windows dan Linux), portabel dan instalasi nol diperlukan. Oleh karena itu tidak seperti yang lain (sejauh yang saya ketahui) itu dapat dimasukkan ke perangkat penyimpanan dan dijalankan pada mesin apa pun yang terhubung ke penyimpanan, tanpa terlebih dahulu harus menginstal aplikasi pada mesin. Ini termasuk Wiki dan sistem pelacakan perubahan / cacat dengan repo. Ini juga memiliki gui bawaan.

Saya belum menggunakannya dengan serius (saya kebanyakan menggunakan GIT), tetapi terkesan dengan pendekatannya yang ringan dan dimasukkannya Wiki dan pelacak cacat menjadikannya ideal untuk proyek kecil. Satu-satunya kekhawatiran saya adalah bahwa beberapa fitur yang lebih kuat dari GIT mungkin tidak mungkin, dan tidak seperti GIT, komunitas pengguna tidak begitu besar sehingga mudah untuk menemukan jawaban atas pertanyaan.


Meskipun Git mengambil perintah Unix untuk melakukan satu hal dan melakukannya dengan sangat serius, Anda dapat memiliki fitur-fitur ini di Git melalui ekstensi seperti ticgit (sistem tiket) dan gollum (wiki berbasis repo).
Jason Lewis

@Jason Lewis: Anda benar, dan karena bersifat open source, Anda dapat memodifikasinya untuk memenuhi persyaratan Anda, jadi GIT (atau alat lainnya) dapat menjadi segalanya bagi siapa saja (yang dapat diganggu, memiliki waktu luang dan sumber daya untuk mengunduh, menginstal, dan men-debug semua "plugin". Yang saya katakan adalah solusi yang "Hanya berfungsi di luar kotak", ada baiknya mempertimbangkan Fosil.
mattnz

1

Menggunakan DCVS mungkin ide yang bagus, tetapi itu bukan satu-satunya pilihan.

Saya memiliki repositori CVS kecil di USB thumb drive. Ketika saya ingin mengaksesnya, saya hanya perlu menggunakan cvs -d <path>atau mengatur $CVSROOTpath dari repositori (yang tentu saja memerlukan thumb drive untuk dipasang pada sistem).

Jika Anda sudah terbiasa menggunakan CVS, ini seharusnya bisa diterapkan. Hal yang sama harus berlaku untuk SVN. Itu artinya repositori pusat Anda ada di thumb drive, dan tidak selalu terlihat.

Ada argumen untuk menggunakan DCVS daripada CVS secara umum. Saya tidak berpikir argumen-argumen itu secara khusus dipengaruhi oleh apakah repositori pusat ada di thumb drive atau di tempat lain. Misalnya, Anda bisa dengan mudah membuat repositori git pada thumb drive.


1
Saya biasanya bukan penggemar DVCS, tapi saya pikir DVCS akan lebih baik dalam hal ini. Masalah dengan VCS yang tidak terdistribusi adalah bahwa repo adalah titik kegagalan tunggal. Jika itu duduk di pusat data yang dikendalikan iklim dan didukung secara teratur, itu bukan masalah besar - tetapi sesuatu seperti thumb drive akan hilang (atau diinjak, dimakan oleh anjing, atau jatuh ke Rusia Putih) lebih cepat atau nanti.
Mike Baranczak

1
@MikeBaranczak: Poin bagus - tetapi apa pun yang ada di thumb drive harus dicadangkan secara teratur, apakah itu repositori CVS atau tidak.
Keith Thompson

dengan sistem terdistribusi, setiap klien sudah memiliki salinan lengkap dari repo. Jadi tidak ada alasan untuk prosedur "pencadangan" yang terpisah.
Mike Baranczak

1
@MikeBaranczak: Tentu, itu alasan yang bagus untuk menggunakan DCVS. Maksud saya adalah bahwa pilihan DCVS vs sistem terpusat tidak tergantung pada apakah Anda menggunakan thumb drive atau tidak.
Keith Thompson

0

Sebagai tambahan untuk jawaban lain:

Walaupun DVCS sangat cocok dengan masalah ini, Anda secara teknis bisa juga menggunakan Subversion, jika Anda merasa lebih nyaman dengannya. Subversi dapat menggunakan direktori lokal alih-alih server pusat. Anda bisa memasukkannya ke dalam thumb drive, dan menggunakannya.

Kerugiannya, dibandingkan dengan DVCS, adalah bahwa Anda hanya dapat bekerja dengan Subversion (yaitu komit, lihat log, dll.) Ketika thumb drive dicolokkan. Juga, itu harus selalu berupa thumb drive yang sama (atau setidaknya sebuah up salinan-to-date), karena dengan Subversion Anda tidak boleh menggunakan lebih dari satu repositori (itu adalah bagian yang tidak didistribusikan). Jadi jika Anda pernah lupa thumb drive Anda, Anda tidak dapat menggunakannya, tidak seperti dengan Git atau Mercurial.

catatan:

Seperti dijelaskan di atas, dan dalam komentar, DVCS benar-benar lebih cocok untuk masalah Anda. Saya hanya menyebutkan Subversion demi kelengkapan, dan jika Anda memiliki alasan khusus untuk menggunakan Subversion.


1
Seperti dengan jawaban Keith , masalah dengan VCS di direktori lokal adalah bahwa itu adalah satu titik kegagalan. Juga, jika Anda berpindah dari mesin A ke mesin B tetapi membiarkan thumb drive dicolokkan ke mesin A, maka Anda cenderung tidak peduli jika Anda menggunakan DVCS (Anda selalu dapat menggabungkan perubahan lokal Anda nanti) sedangkan dengan VCS , Anda harus kembali ke mesin A, dapatkan drive dan kembali ke mesin B sebelum Anda dapat melanjutkan.
Mark Booth

@ MarkBooth: Saya tidak menganjurkan solusi ini, saya hanya ingin menunjukkan itu ada, demi kelengkapan dan dalam kasus OP memiliki beberapa preferensi khusus untuk Subversion. Saya mengedit jawaban saya untuk memperjelas ini.
sleske

Terima kasih @sleske, saya setuju bahwa preferensi untuk svn(atau bahkan Cvs) dapat mempertimbangkan penggunaan solusi itu, tetapi untuk kepentingan pengungkapan penuh, kelemahan dari pendekatan itu juga harus disebutkan. Jangan ragu untuk mengedit poin dari komentar saya ke dalam jawaban Anda. Jika ya, saya akan dengan senang hati membersihkan (menghapus) komentar saya. * 8 ')
Mark Booth

Saya tidak yakin apa jawaban ini menambahkan bahwa saya belum mengatakannya pada saya.
Keith Thompson

1
@KeithThompson: Ini menambahkan informasi bahwa SVN dapat menggunakan direktori lokal alih-alih server pusat. Itu dijelaskan dalam dokumen SVN, tetapi karena kebanyakan orang menggunakan SVN melalui server pusat, mungkin tidak jelas bahwa SVN tidak memerlukan server.
sleske
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.