Apa sistem kontrol versi favorit Anda? [Tutup]


41

Ini lebih merupakan pertanyaan diskusi daripada upaya yang sebenarnya untuk menentukan yang "terbaik", karena itu jelas berbeda dengan kebutuhan organisasi. Saya lebih ingin tahu tentang argumen yang mendukung sistem yang berbeda di seluruh kategori (terpusat vs terdistribusi, terbuka vs berpemilik, dll).

Jadi, apa yang Anda pikirkan adalah sistem kontrol versi terbaik?


1
en.wikipedia.org/wiki/Comparison_of_revision_control_software adalah tabel perbandingan yang bagus untuk hal ini. Pertanyaan diskusi ... komunitas wiki?
Chris

4
Yang pertama mengepos nama, mendapat perwakilan ... Ini harusnya komunitas wiki.
takeshin


Tidak menyadari ini sudah menjadi wiki Komunitas .
takeshin

Jawaban:


81

Lincah

Karena kemampuannya yang canggih untuk bercabang dan menggabungkan kode, ini adalah yang terbaik yang saya gunakan. Seluruh paradigma DVCS sangat masuk akal. Saya belum pernah menggunakan Git, tapi saya kira itu memenuhi syarat juga.


Saya harus mencoba Mercurial sejak saya sudah mencoba 2 dari 3 besar. Dan karena Google Code mendukungnya ...
TheLQ

2
Mercurial manis jika Anda menggunakan Netbeans. Integrasi IDE sempurna.
Seun Osewa

4
Saya lebih suka Mercurial hanya karena TortoiseHg lebih dewasa daripada TortoiseGit :-) (seluruh pengalaman di Windows juga jauh lebih baik di Mercurial)
Dean Harding

+1, saya sarankan menjadikan Mercurial lebih berani dan lebih besar (seperti yang dilakukan Gaurav dalam jawabannya)
Tim Post

Mercurial cukup manis. Saya dan tim saya telah menggunakannya selama sekitar 2 bulan dan ini menghirup udara segar dibandingkan dengan SVN.
Gary Willoughby

72

Git

Git luar biasa, dan saya terutama akan merekomendasikannya kepada siapa pun yang bekerja pada proyek-proyek open source: jauh lebih mudah untuk menyumbangkan perubahan kecil, satu kali untuk sebuah proyek di Git, terutama jika itu dihosting di GitHub, daripada berurusan dengan e- mengirimkan patch tentang dengan SVN.

Satu peringatan besar bagi pengguna Windows: Git's Windows tools, meskipun pasti bisa digunakan, tidak cukup untuk menggaruk. Ketika saya terpaksa menggunakan Windows untuk sementara waktu, saya mencoba antarmuka Windows Mercurial dengan alat integrasi Hg-Git sehingga saya bisa menggunakan repositori Git saya, dan ternyata jauh lebih mudah digunakan.


5
Saya pikir penting untuk mengatakan bahwa git itu sulit. Saya sangat menyukainya, tetapi itu bukan sesuatu yang dapat Anda gunakan untuk mempelajarinya dalam beberapa hari. Anda harus menggunakannya sebentar dan menjadi marah sampai Anda dapat beralih ... ;-)
Khelben

1
@Helben - Ada beberapa kebenaran dalam hal itu, ya. Namun, itu juga tampaknya memiliki jumlah literatur / artikel / tutorial terbesar di internet yang didedikasikan untuk itu. Saya secara teratur menemukan buku-buku Git keluar, Mercurial - tidak begitu banyak (menggunakan Mercurial di sini sebagai kontras, karena dalam banyak hal mirip dengan Git). Tidak bisa mengatakan apakah itu baik atau buruk, tetapi tampaknya orang menggunakannya.
Benteng

2
msysgit dapat digunakan di bawah Windows.

1
Saya berasumsi bahwa git, Mercurial dll semua cukup bagus, tetapi saya memilih git karena auf GitHub. GitHub terasa lebih baik daripada situs yang sebanding dan banyak proyek penting di-host di sana. GitHub menurunkan penghalang untuk berkontribusi banyak pada Open Source.
LennyProgrammers

2
Mercurial tidak PERLU buku.
Warren P

24

Peringatan: Sejak posting ini saya menemukan Mercurial dan menyukainya jauh lebih baik daripada SVN. Jadi posting ini agak ketinggalan zaman dengan komentar Pro SVN dan anti-DVCS umum, tetapi hal-hal anti-git masih relevan


Saya penggemar SVN atas Git.

Mengapa? Karena SVN jauh lebih mudah untuk satu pengembang atau tim kecil, dan git (khususnya msysgit) membuat saya tidak enak.

Ketika saya magang di sebuah toko kecil, saya diperkenalkan dengan git di Windows. Saya segera memperhatikan jumlah pekerjaan yang diperlukan untuk membuatnya bekerja dengan Github. Pertama, saya harus membuat kunci pribadi ssh, menempelkan kunci publik di Github, kemudian membuka kontes dan membuka kunci pribadi saya setiap kali saya ingin mendorong, yang sangat menjengkelkan.

Dan saya tidak pernah benar-benar menyukai bahwa saya merobohkan seluruh repositori. Saya akan mengakui bahwa saya tidak pernah bekerja dengan sesuatu yang besar, tetapi saya akan takut untuk mengunduh repositori KDE di Git jika seluruh repo dan revisinya ada di HD saya.

Lalu ada proses yang membingungkan untuk membuat komitmen. TMK, saya harus pertama "tahap" semua file yang ingin saya komit (yang tersedot ketika Anda memiliki banyak banyak file, butuh beberapa saat untuk menemukan perintah manual untuk mem-stage semuanya), kemudian lakukan komit, kemudian dorong ke utama repo (mengapa itu operasi yang terpisah ?!).

Anda juga memiliki data komit tidak (!) Yang sangat membantu. Oh, lihat, ini adalah bagian komitmen 14f74433245ae17aeeaa dari pohon 2167a4934d0a4a7db0de dan induk d7042abb4821d3faf600. Apa artinya itu? Saya harus bisa memikirkan hal-hal dengan cukup cepat dan tidak perlu berkonsultasi dengan beberapa dokumentasi aneh.

Berbicara tentang dokumentasi, setidaknya ketika saya menggunakannya, sepertinya semuanya dalam format file linux man, IE membingungkan dan tidak berguna bagi saya. Saya jarang dapat menemukan banyak bantuan dalam dokumen dan hanya beralih ke google.

Dan dengan komitmen, satu hal yang saya tidak suka adalah kurangnya nomor versi. Sekarang saya tahu ini karena desain git, tetapi perangkat lunak apa pun membutuhkan nomor versi. Saya masih ingat komit penanda yang akan muncul mengatakan "Mengubah versi ke 1.8.6" atau sesuatu yang serupa, tetapi Anda masih tidak bisa membuat angka. Bagi saya memiliki versi menjadi 1.8.6.5164 (bagian terakhir adalah nomor revisi) memberi tahu saya lebih dari sekadar 1.8.6 dan catatan yang mengatakan bahwa sesuatu yang kecil berubah, cobalah

Semakin spesifik perangkat lunak, program dasar pada Windows adalah msysgit, yang merupakan antarmuka yang mengerikan. Itu terkunci pada saya beberapa kali, memiliki antarmuka yang mengerikan, dan integrasi CLI-GUI sangat rapuh. Pecandu baris perintah di sekitar saya semakin membenci gui.


Sekarang mari kita lihat SVN. Dan karena saya menggunakan Windows dan memiliki akun google, khususnya TortoiseSVN dan Google Code.

Pertama, integrasi shell lengkap untuk melakukan segalanya pada repositori (dan bagi Anda orang linux, RabbitVCS melakukan hal yang sama), tidak diperlukan GUI utama. Mendapatkan repositori semudah checkout, tidak perlu SSH (tidak ingat apakah Github membutuhkan SSH untuk menarik), dan tidak ada seluruh repo + semua komitmen masa lalu yang tersimpan di HD Anda.

Berkomitmen itu ekstrem mudah, terutama karena tidak diperlukan SSH atau pementasan. Anda cukup memeriksa semua file yang ingin Anda gunakan dengan sangat membantu pilih semua opsi yang dalam versi msysgit saya tidak tersedia, ketik pesan komit, dan tekan komit. Google Code kemudian meminta Anda untuk informasi login Anda (yang kebanyakan klien simpan), dan Anda selesai. Sederhana, mudah, dan tidak ada SSH

Nomor versi? Dengan beberapa kode mudah, Anda dapat menambahkan nomor versi dan nomor komit ke semua checkout, yang membuat semuanya jadi lebih mudah. Anda juga mendapatkan nomor versi yang dapat digunakan yang benar-benar menunjukkan perubahan, misalnya 1.8.6.5165 lebih baru dari 1.8.6.5164.

Dokumentasi? Yah, sulit dikatakan. Kura-kura didokumentasikan, tetapi saya belum benar-benar merujuk ke dokumentasi resmi sedemikian lama sehingga saya tidak bisa menilai. Membaca panduan intro sederhana sudah cukup bagi saya.

Penggabungan adalah hal lain yang tidak bisa saya bandingkan. Saya harus melakukannya sekali di Git ketika orang lain melakukan perubahan pada file yang sedang saya kerjakan, tetapi tidak pernah di SVN.


Mana yang akan saya rekomendasikan? Baik di tim besar, git memang memiliki kelebihan, terutama dalam siklus pengembangan non-liniernya. Dalam proyek lain saya melihat 4 pemrogram memulai di cabang terpisah, kemudian menggabungkan semua kode dengan cara yang sangat aneh yang entah bagaimana berubah menjadi cabang master akhir. Github dan msysgit memiliki alat visualisasi yang sangat bagus untuk seluruh proyek yang sangat saya sukai.

Untuk pengembang tunggal atau proyek tim kecil, SVN akan menjadi yang terbaik karena sebagian besar fitur Gits tidak digunakan dan Anda hanya mendapatkan bagian negatifnya. Kesederhanaan adalah hal yang menyenangkan


6
Penggabungan dengan SVN cukup berisiko (dibandingkan dengan git). Itu satu hal yang penting untuk dicatat pada perbandingan apa pun.
Khelben

5
Mengapa Anda perlu "membuka kontes" setiap saat? Itu agen kunci. Anda hanya perlu membawanya sekali, ketika Anda masuk ke mesin Anda. Anda menambahkan kunci Anda, dan Anda selesai . (Dan Anda dapat membuatnya lebih mudah dengan mengaitkan keyfile Anda dengan pageant dan menambahkannya ke folder startup Anda. Log on, itu muncul dengan dialog yang meminta Anda untuk frasa sandi Anda.)
Frank Shearar

3
@ Torbjoern @ Frank Shearer: Saya pikir fakta bahwa Anda mengatakan "Anda bisa melakukan ini, atau Anda bisa melakukan itu, dan tidak memiliki masalah itu" menyoroti intinya: Itu adalah solusi untuk masalah atau masalah. Ini bukan masalah dengan beberapa VCS lain.
Steven Evers

4
Jawaban ini mengejutkan saya karena banyak mengeluh dan mengeluh tentang sesuatu yang jelas-jelas tidak perlu dipahami oleh poster itu. Saya telah menghabiskan banyak waktu di kedua git dan svn, di kedua linux dan windows, dan akan bersaksi bahwa git jauh lebih unggul daripada svn, dalam konsep, model data, pemahaman, dan kegunaan.
gahooa

4
@TheLQ Tidak. Ini sama sekali bukan "mentalitas Linux Anda". Ini hal yang sederhana untuk diatur, didokumentasikan dengan baik, Putty adalah suite aplikasi Windows yang sangat baik yang membuat hal-hal yang benar-benar sangat mudah digunakan. Dan Anda benar-benar harus mengenkripsi transfer kode Anda, jika Anda bekerja melalui jaringan publik apa pun. Dan itu menghina bagi pengguna Windows untuk menganggap mereka terlalu bodoh untuk belajar bagaimana menggunakan alat yang seharusnya mereka gunakan. Saya tidak meminta orang untuk melakukan sesuatu. Saya meminta mereka untuk mengenkripsi info penting mereka.
Frank Shearar

22

Kutipan berikut dari Q4TD cukup meringkaskannya bagi saya:

“Saya mencintai Git sampai saya mencobanya. Sekarang saya suka Mercurial. "

        - Tor Norbye, The Java Posse Podcast

Juga, hgsubversion membuat klien subversi yang cukup bagus untuk Linux (di mana saya biasanya menggunakan baris perintah, tidak seperti Windows di mana saya biasanya menggunakan TortoiseSVN). Keuntungan terbesar: tidak ada .svnsub-folder di setiap folder, hanya .hgdi tingkat atas.

Pembaruan: Menanggapi permintaan Alex di komentar untuk "katakan lebih banyak tentang mengapa git tidak bekerja untuk Anda, dan bagaimana Mercurial bekerja lebih baik":

Saya tidak akan mengatakan bahwa Git tidak bekerja untuk saya, tetapi Murcurial berfungsi lebih baik IMO.

Singkatnya, ini Mercurial:

teks alternatif

dan ini adalah Git:

teks alternatif

Dan saya menegaskan bahwa Mercurial akan melakukan semua hal yang sebagian besar pengembang perlu lakukan, tanpa harus mencari manual untuk mencari tahu bagaimana melakukan hal-hal sehari-hari.

Memang, saya hanya menggunakan Git sesekali, tetapi komunitas pemrograman telah membahas bahasa seperti Ruby dan Python, sebagian, untuk keringkasan dan keanggunan mereka, sedangkan Git terasa seperti unta yang dirancang oleh komite unta.

Bah, sekarang lihat apa yang sudah kamu lakukan? Kata-kata kasar di semua tempat. Bergerak, tidak ada yang melihat ... tidak ada yang melihat ...

Pembaruan 2: Dan tweet lain yang baru saja saya jumpai:

"Git semakin mudah setelah Anda mendapatkan gagasan dasar bahwa cabang adalah endofunctor homeomorfik yang memetakan sub-manifold ruang Hilbert."


Pernah mencoba RabbitVCS?
TheLQ

Tidak, tapi saya menggunakan KDE, bukan Gnome sehingga tidak cocok untuk saya. Saya kadang-kadang akan menggunakan klien SVN grafis di Linux, tetapi hanya benar-benar ketika melakukan sesuatu yang agak esoterik seperti menjelajahi repositori atau membandingkan revisi sebelumnya. Bukan untuk hal-hal sederhana add / remove / commit / log Baris perintah lebih cepat.
Evan

2
Bisakah Anda mengatakan lebih banyak tentang mengapa git tidak bekerja untuk Anda, dan bagaimana Mercurial bekerja lebih baik? Itu akan sangat menarik untuk dibaca.
Alex Feinman

Saya cukup yakin penggambaran Git kehilangan pisau cukur lurus panjang 6 "...
Tim Post

2
@Tim: rebase? Mungkin di sisi lain.
Alan Pearce

14

Saya tidak memiliki sistem kontrol versi "terbaik", melainkan paradigma VCS terbaik tunggal.

Saya telah menggunakan beberapa sistem kontrol versi terpusat yang berbeda dan beberapa sistem kontrol versi terdistribusi yang berbeda. Dan saya dapat mengatakan tanpa ragu-ragu bahwa tidak ada seorang pun yang dapat menyebabkan CVCS pada diri mereka sendiri.

Saya tidak peduli DVCS mana yang Anda pilih (favorit saya adalah Git), tapi tolong bantu diri Anda dan gunakan DVCS. Untuk satu: Anda akan jauh lebih fleksibel. DVCS dapat dengan mudah mengemulasi alur kerja CVCS (tidak pernah memotong repositori, dan memperlakukan repositori lokal Anda hanya sebagai chache alih-alih garpu independen), sedangkan sebaliknya tidak mungkin dilakukan. Dan sementara secara logis, melakukan emulasi ini harus membawa beberapa overhead (dan memang itu), saya masih merasa lebih mudah untuk digunakan (belum lagi lebih banyak performan karena caching lokal) daripada CVCS yang saya gunakan.


3
Ini jawaban yang bagus. Tidak ada satu VCS "terbaik", tapi saya setuju sepenuhnya bahwa seseorang harus menggunakan DVCS.
Nick Hodges

Jadikan milikku DVCS, tapi peganglah endofunctor pemetaan homeomorfik submanifol ruang Hilbert. Ergo, Mercurial.
Warren P

11

Tidak dapat mengatakan bahwa saya telah menemukan perangkat lunak kontrol versi Terbaik, tetapi saya dapat memberitahu Anda untuk menjauh dari VSS dan MKS. Keduanya adalah anjing yang harus dihindari bagaimanapun caranya.


7

Saya tidak akan mengatakan yang terbaik, tetapi satu dengan fitur dan konsep yang sangat menarik.

Fossil adalah kontrol versi terdistribusi, pelacakan bug, dan proyek wiki yang dibangun di atas basis data SQLite sebagai repositori.


5

Server Yayasan Tim

Karena:

  1. Ini adalah yang baik, VCS padat . (Saya tidak akan menganggapnya yang terbaik dengan cara apa pun, tetapi memiliki tambahan yang bagus.)
  2. Pelacakan tugas dan bug bawaan yang terintegrasi ke dalam Visual Studio membantu saya tetap fokus dan tahu apa yang harus saya kerjakan di satu tempat (secara otomatis menerapkan check-in ke bug atau tugas dan menutupnya cukup bagus, meskipun Anda bisa dapatkan plugin untuk sistem lain / eclipse / etc untuk melakukan ini.)
  3. Ini mengintegrasikan tugas / pelacakan bug / proyek langsung ke Server Proyek sehingga saya jarang harus selalu memperbarui rencana proyek atau jadwal waktu. Pembaruan untuk proyek di Project Server secara otomatis menyaring sebagai tugas ke TFS dan ke Visual Studio untuk saya lihat secara otomatis.

2
Saya ingin tahu bagaimana perasaan Anda tentang alur kerja Anda yang terbatas pada Visual Studio untuk hampir semua pekerjaan pengembangan. Juga, apakah Anda harus melakukan pengaturan infrastruktur untuk TFS? Pengalaman saya berlawanan dengan pengalaman Anda dengan cara ini: # 1 - VCS tidak mudah digunakan, sering tidak stabil, dan mode offline dibuat oleh setan sendiri. # 2 Pelacakan tugas dan bug bawaan rumit dibandingkan dengan alat lain, jadi # 3 tidak relevan bagi kami dan membuat pekerjaan duplikat. Saya telah menggunakannya 3 kali berbeda sekarang dengan hasil buruk yang sama setiap kali.
Jordan

1. Saya setuju dengan mode mengisap secara offline. Saya tidak punya banyak masalah sama sekali online, tetapi saya selalu terhubung. Banyak kontrol VCS, terutama dengan folder remapping sebenarnya tersembunyi jauh di dalam menu. Apakah itu masalah yang Anda alami? 2. Ini jelas lebih rumit, tetapi menyimpan pekerjaan secara keseluruhan untuk tim saya yang terintegrasi dengan server Proyek. 3. Bagaimana cara membuat duplikat bekerja? Apakah Anda menduplikasi tugas di server proyek dan TFS? Ada plugin open source untuk 2007 dan beta untuk 2010 yang memungkinkan mereka disinkronkan satu sama lain.
Ryan Hayes

1
Itu menyempitkan saya ke VS, tapi kami benar-benar toko .NET. Saya menggunakan TFS dengan proyek Java saya di rumah. Coba SVNBridge di svnbridge.codeplex.com yang memungkinkan Anda menggunakan Tortoise dengan TFS. Jika Anda menggunakan Tortoise (seperti kebanyakan orang Jawa, ruby, non-.net) maka itu akan membantu Anda dengan alur kerja Anda di proyek lain.
Ryan Hayes

4

Saya telah menggunakan banyak sistem kontrol versi dalam sejarah panjang saya:

  • RPPT - (Gulungan Pita Kertas Punched). Dalam kotak sepatu. Aku tidak bercanda.
  • PVCS - (Sistem Kontrol Versi Polytron). VCS nyata pertama yang saya gunakan.
  • SCCS - dulu sekali, saya tidak ingat hal baik atau buruk tentang itu.
  • RCS - seperti yang ditunjukkan orang lain, lebih suka mengisap bola keledai yang berkeringat.
  • CVS - itu hanya rasa sakit ketika digunakan dengan lebih dari 2 programmer. fitur terbaik: rcs2cvs.
  • VSS - itu berfungsi, kecuali pada hari Selasa, ketika itu merusak seluruh repositori Anda.
  • Perforce - harganya lebih mahal dari mobil saya. VCS itu sendiri dapat diterima, tetapi orang-orang brengsek IT yang mengendalikan setiap aspek menggunakannya tidak akan pernah mendarat di daftar "pilihan" saya.
  • SVN - percabangan dan penggabungan adalah menyebalkan, tetapi secara umum itu lebih baik daripada yang sebelumnya. Tidak begitu baik dengan banyak perubahan kecil yang luar biasa menunggu ulasan.
  • Mercurial - sedikit pengalaman yang saya miliki dengan itu, saya suka. Saya mungkin mencobanya di proyek saya berikutnya.
  • Git - tidak pernah memiliki kesempatan untuk menggunakannya.

Meskipun pasangan adalah kengerian, kebanyakan "baik-baik saja". Mereka tidak menghalangi saya. Selama alat tidak membuat hidup saya jauh lebih sulit , saya tidak keberatan.

Hal yang nyata adalah memahami kekuatan dan kelemahan masing-masing. Memahami lingkungan target:

  • didistribusikan atau lokal
  • tim kecil atau besar
  • layanan host vcs atau tidak
  • integrasi yang mudah ke alat lain

Joel juga keluar dengan pengamatan penting: Pelajari alat dan model penggunaan yang sebenarnya. Dia berjuang sekuat tenaga untuk membuat Mercurial berperilaku seperti Subversion.


1
Kalau saja komentar pada VSS adalah lelucon ... hindari seperti wabah.
DevSolo

Ah, PVCS, kenangan yang membawa kembali :) Apa sampah itu.
Henry

Daftar itu mengingatkan saya pada bahasa "menembak diri sendiri di kaki". +1
Orbling

Saya ingat hal-hal buruk tentang SCCS, tetapi secara umum dapat digunakan. Saya ingat mencoba melakukan pekerjaan simultan pada file dengan SCCS dan programmer lain, dan itulah sebabnya saya jatuh cinta dengan CVS ketika saya melihatnya.
David Thornley

Visual SourceSafe, A VCS terutama untuk programmer yang ingin mencungkil mata mereka dengan sendok.
Mark Booth

2

Satu sistem yang lebih baru yang kami gunakan di kantor saya adalah Plastic SCM (http://www.plasticscm.com/). Ini bekerja sangat baik untuk tim kecil kami dan memberi kami kontrol besar atas setiap aspek manajemen sumber.


1

SCCS .

Atau, jika Anda kebetulan belum pernah hidup di gua selama 38 tahun terakhir, CSSC .

Serius, perusahaan saya menggunakan TeamWare , yang merupakan semacam pseudo DVCS berdasarkan SCCS.

Tidak, saya tidak bercanda.

Sun beralih ke mercurial dari TeamWare hanya beberapa tahun yang lalu. Sekarang Anda harus mengerti mengapa Java tampak bergerak sangat lambat.


1

MPW: Yah, saya tidak bisa benar-benar memberikan ulasan meskipun saya berusaha.

Ini kembali ketika saya belajar pemrograman di sekolah menengah, dan satu-satunya kompiler C ++ yang benar-benar gratis yang bisa didapat adalah Macintosh Programming Workbench, yang saya simpan di disk zip dan muncul ke mana pun Performa tersedia di lab.

MPW datang dengan lusinan alat (tidak ada yang resedit, itu unduhan terpisah), dan salah satunya adalah utilitas kontrol versi. Itu muncul membuka jendela kecil dengan satu baris teks, dan Anda harus drag and drop proyek atau file Anda ke dalamnya. Tidak ada dokumentasi yang bisa saya temukan, tidak biasa mengingat semua yang lain sepertinya memiliki dokumen yang bagus, jadi saya tidak pernah tahu bagaimana menggunakannya.

Itu kuas pertama saya dengan VC, dan yang terakhir cukup lama. Sekarang saya menggunakan git untuk semuanya.


Proyektor! Pada pekerjaan paruh waktu selama kuliah saya menggunakan versi (ditipu) itu. Waktu yang baik
RyanWilcox

0

RCS - Sistem Kontrol Revisi

Pengodean tunggal menjadi sangat mudah.


Anda bercanda, kan Xepoch? Tolong Tuhan bercanda.
Marc W

Kalian membuatku tertawa. Sebenarnya saya TIDAK menggunakan RCS tetapi HANYA untuk situs web pribadi saya, & c. Saya setengah jalan bercanda tentang menggunakannya untuk pengembangan besar, TETAPI saya melihatnya secara eksklusif digunakan (daripada CVS) pada pengembangan bersama sistem Unix. Jujur, kami tidak punya masalah sama sekali, tetapi TIDAK meminjamkan dirinya untuk apa pun selain fitur server tunggal.
Jé Queue

1
@Xepoch, Anda mungkin lebih baik belajar Git atau Mercurial- DCVS bekerja bagus untuk pengembangan solo.
Fishtoaster

1
Anda tahu apa yang benar-benar menyenangkan tentang RCS? Anda dapat meletakkan semua RCS, v file Anda dalam struktur direktori yang benar dan Anda punya repositori CVS yang hampir siap digunakan. Ada banyak alat yang kemudian dikonversi dari CVS ke sistem modern yang Anda suka, seperti Mercurial.
David Thornley

@ Xepoch, kemudahan untuk mencadangkan vcs'es yang didistribusikan tidak ada duanya.

0

Bukan ClearCase, setidaknya untuk sistem Unix / Linux (mungkin dengan Windows installer lebih mudah). Lebih mudah bagi saya untuk mempelajari alat baru, Perforce, daripada memutakhirkan server ClearCase kami.

Saat ini saya menggunakan Perforce di tempat kerja dan saya menyukainya tetapi saya tidak tahu apakah itu yang terbaik. Menyiapkan lingkungan baris perintah dan Server Perforce agak canggung, tetapi menggunakan Visual Client cukup mudah. Saya suka berpikir para pengguna memiliki waktu yang cukup mudah dengannya untuk tugas sehari-hari; hanya saja pengaturan awal membutuhkan beberapa pekerjaan.


0

Saya telah menggunakan Visual SourceSafe dan membencinya, tapi itu lebih baik daripada tidak sama sekali, tetapi tidak banyak. Selama beberapa tahun terakhir, menggunakan sesuatu yang disebut QCVS oleh Qumasoft.com ditulis, dimiliki dan didukung oleh Jim Voris sang programmer. Gui sederhana, harga murah, dukungan bagus.

Lakukan saja pekerjaan itu.

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.