it-swarm.dev

En sevdiğiniz sürüm kontrol sistemleri hangileridir?

Bu, "en iyiyi" belirlemeye yönelik gerçek bir girişimden ziyade bir tartışma sorusudur, çünkü bu, örgütün ihtiyaçlarına göre açıkça değişir. Kategoriler arasında farklı sistemler lehine olan argümanları daha merak ediyorum (merkezi - dağıtılmış, açık - tescilli vs).

Peki, sizce en iyi sürüm kontrol sistemi nedir?

41
Fishtoaster

Cıvalı

Kodu dallandırma ve birleştirme yeteneğinden dolayı kullandığım en iyisi. Tüm DVCS paradigması çok mantıklı. Git'i kullanmadım, ama sanırım bu da yeterli.

81
epotter

Git

Git fantastik ve özellikle açık kaynak projeleri üzerinde çalışan herkese tavsiye ederim: Git'teki bir projeye, özellikle GitHub'da barındırılıyorsa, e- ile SVN yamaları hakkında.

Windows kullanıcıları için büyük bir uyarı: Git'in Windows araçları, kesinlikle kullanılabilir olsa da, çizilmeye hazır değil. Bir süre Windows'u kullanmaya zorlandığımda, Git depolarımı kullanabilmem için Mercurial'ın Windows arayüzünü bir Hg-Git entegrasyon aracıyla denedim ve kullanımının çok daha kolay olduğunu gördüm.

72
Gaurav

Uyarı: Bu yazıdan beri Mercurial'ı buldum ve SVN'den çok daha iyi seviyorum. Bu yazı, Pro SVN yorumları ve genel anti-DVCS ile biraz güncel değil, ancak anti-git şeyler hala alakalı


Ben SVN Git hayranıyım.

Neden? Çünkü SVN tek bir geliştirici veya küçük ekip için çok daha kolaydı ve git (özellikle msysgit) beni ağzımda kötü bir tat bıraktı.

Küçük bir dükkanda staj yaparken, Windows'ta git ile tanıştım. Github'la çalışmak için gereken iş miktarını hemen fark ettim. İlk olarak, bir ssh özel anahtar oluşturmak, ortak anahtarı Github'a yapıştırmak, sonra her zaman itmek istediğimde pageant getirmek ve özel anahtarımı açmak zorunda kaldım, ki bu son derece sinir bozucuydu.

Ve tüm depoyu indirmemden hiç hoşlanmadım. Asla çok büyük bir şeyle çalışmadığımı itiraf edeceğim, ancak tüm repo ve revizyonları HD'mde ise KDE'nin Git'teki deposunu indirmekten korkarım.

Sonra bir taahhütte bulunmak için kafa karıştırıcı bir süreç vardı. TMK, önce taahhüt etmek istediğim tüm dosyaları "sahne" etmek zorunda kaldım (çok fazla dosyanız olduğunda emdi, her şeyi sahneye koymak için manuel komutu bulmam biraz zaman aldı), sonra taahhüdü yap, sonra ana repo (bu neden ayrı bir işlem ?!).

Ayrıca çok yararlı değil taahhüt verileri vardı. Oh bak, bu taahhüt 14f74433245ae17aeeaa ağacın bir parçası 2167a4934d0a4a7db0de ve ebeveyn d7042abb4821d3faf600. Bu ne demek oluyor? İşleri oldukça hızlı bir şekilde çözebilmeliyim ve bazı garip belgelere başvurmak zorunda değilim.

Belgelerden bahsetmişken, en azından onu kullanırken, her şey linux man dosya formatında, IE kafa karıştırıcı ve benim için işe yaramaz gibi görünüyordu. Ben nadiren dokümanlar çok yardım bulabilir ve sadece başvurdu google.

Ve taahhütlerle, sevmediğim tek şey sürüm numaralarının olmamasıydı. Şimdi bunun git tasarımından kaynaklandığını biliyorum, ancak herhangi bir yazılımın sürüm numarasına ihtiyacı var. Hala "1.8.6 sürümü değiştirildi" ya da benzer bir şey söyleyerek açılacak marka taahhütlerini hatırlıyorum, ancak yine de sayı yapamıyorsunuz. Bana göre sürüm 1.8.6.5164 (son bölüm revizyon numarası) bana sadece 1.8.6'dan çok daha fazlasını ve küçük bir şeyin değiştiğini söyleyen bir not söyledi, denemek

Yazılıma özgü olarak, Windows'daki temel program, korkunç bir arayüz olan msysgit'dir. Bana birkaç kez kilitlendi, korkunç bir arayüz vardı ve CLI-GUI entegrasyonu en iyi iffy oldu. Çevremdeki komuta hattı gui'den daha fazla nefret ediyordu.


Şimdi SVN'ye bakalım. Windows'da olduğum ve özellikle TortoiseSVN ve Google Code gibi bir google hesabım olduğu için.

İlk olarak, depodaki her şeyi yapmak için Shell entegrasyonunu tamamlayın (ve linux insanlar için RabbitVCS aynı şeyi yapar), ana GUI'ye gerek yoktur. Bir depo almak bir ödeme olarak kolaydır, SSH'ye gerek yoktur (Github'un çekmeler için SSH gerektirip gerektirmediğini hatırlayamazsınız) ve tüm repo + HD'nizde oturmuş tüm taahhütler yoktur.

Taahhüt son derece kolaydır, çünkü esas olarak SSH veya evreleme gerekli değildir. Sadece msysgit sürümümün mevcut olmadığı çok yararlı tüm seç seçeneğini kullanarak istediğiniz tüm dosyaları kontrol edin, bir taahhüt mesajı yazın ve taahhütlü düğmesine basın. Google Code daha sonra sizden giriş bilgilerinizi (çoğu müşterinin sakladığı) ister. Basit, kolay ve SSH yok

Sürüm numaraları? Bazı kolay kodlarla, tüm kasalara bir sürüm numarası ve bir taahhüt numarası ekleyebilirsiniz, bu da işleri çok daha kolay hale getirir. Ayrıca aslında bir değişiklik gösteren kullanılabilir sürüm numaraları da alırsınız, örneğin 1.8.6.5165, 1.8.6.5164'ten daha yenidir.

Belgeler? Söylemesi zor. Kaplumbağa belgelenmiştir, ancak yargılayamayacağım kadar uzun zamandır resmi belgelere başvurmadım. Basit bir giriş kılavuzu okumak benim için yeterliydi.

Birleştirme, karşılaştıramayacağım başka bir şey. Birisi çalıştığım dosyada bir değişiklik yaptığında Git'te bir kez yapmak zorunda kaldım, ancak hiçbir zaman SVN'de yapmadım.


Hangisini öneririm? Büyük ekiplerde git, özellikle doğrusal olmayan geliştirme döngüsünde avantajlarına sahiptir. Başka bir projede 4 programcının ayrı dallarda başladığını gördüm, sonra tüm kodu son ana dalda bir şekilde dönüştüğü çok garip yollarla birleştirdim. Github ve msysgit, gerçekten sevdiğim tüm proje için gerçekten güzel bir görselleştirme aracına sahipti.

Tek geliştirici veya küçük ekip projeleri için, Gits özelliklerinin çoğu kullanılmadığı ve yalnızca olumsuz parçalarını aldığınız için SVN en iyisi olacaktır. Sadelik çok güzel bir şey

24
TheLQ

Aşağıdaki alıntı Q4TD benim için hemen hemen özetliyor:

“Git'i deneyene kadar Git'i sevdim. Şimdi Mercurial'ı seviyorum. ”

- Tor Norbye, Java Posse Podcast

Ayrıca, hgsubversion Linux için oldukça iyi bir Subversion istemcisi yapar (burada genellikle komut satırını kullanırım, genellikle TortoiseSVN'yi kullandığım Windows'un aksine). En büyük avantaj: hayır .svn her klasördeki alt klasör, sadece .hg üst düzeyde.

Güncelleme: Alex'in yorumlarında "git'in sizin için neden işe yaramadığı ve Mercurial'ın nasıl daha iyi çalıştığı hakkında daha fazla bilgi" isteğine yanıt olarak:

Git'in benim için çalışmadığını, ancak Murcurial'ın daha iyi IMO çalıştığını söyleyemem.

Özetle, Mercurial:

alt text

ve bu Git:

alt text

Ve Mercurial'ın gündelik şeylerin nasıl yapılacağını anlamak için kılavuza bakmadan çoğu geliştiricinin yapması gereken her şeyi yapacağını iddia ediyorum.

Kuşkusuz, Git'i sadece ara sıra kullandım, ancak programlama topluluğu Ruby ve kısmen Python gibi diller üzerinde gagalama yapıyor, oysa Git bir deve gibi hissediyor bir deve komitesi tarafından tasarlandı.

Bah, şimdi ne yaptığına bak. Her yerde rant var. Hareket et, görecek bir şey yok ... görecek bir şey yok ...

Güncelleme 2: Ve başka bir apropos Tweet Az önce karşılaştım:

“Dalların, Hilbert uzayının altmanifoldlarını eşleyen homeomorfik endofunktörler olduğu temel fikrini aldıktan sonra Git kolaylaşıyor.”

22
Evan

Tek bir "en iyi" sürüm kontrol sistemim yok, tek bir en iyi VCS paradigması var.

Birden çok farklı merkezi sürüm kontrol sistemi ve çok sayıda farklı dağıtılmış sürüm kontrol sistemi kullandım. Ve tereddüt etmeden söyleyebilirim ki, hiç kimse kendi üzerine bir CVCS uygulamamalıdır.

Umursamıyorum hangi Seçtiğiniz DVCS (benim favorim Git'tir), ancak lütfen kendinize bir iyilik yapın ve bir DVCS kullanın. Birincisi: Çok daha esnek olacaksınız. DVCS'ler, bir CVCS iş akışını önemsiz bir şekilde taklit edebilir (sadece depoyu çatallamayın ve yerel depolarınıza yalnızca bağımsız bir çatal yerine bir chache olarak davranmayın), bununla birlikte tersi mümkün değildir. Ve mantıklı bir şekilde, bu öykünmeyi yapmak gerekir bazı yükü taşımak (ve gerçekten de taşır), ben hala kullanımı daha kolay buluyorum (yerelden çok daha fazla performanstan bahsetmiyorum) önbellekleme) kullandığım herhangi bir CVCS'den daha fazla.

14
Jörg W Mittag

En iyi sürüm kontrol yazılımı ile karşılaştığımı söyleyemem, ancak VSS ve MKS'den uzak durmanızı söyleyebilirim. Her ikisi de kaçınılması gereken köpeklerdir.

11
Walter

En iyisini söylemem ama çok ilginç özellikleri ve konseptleri olan biri.

Fossil , SQLite veritabanında depo olarak oluşturulmuş dağıtılmış bir sürüm kontrolü, hata izleme ve wiki projesidir.

7
Maniero

Takım Temel Sunucusu

Çünkü:

  1. Bu bir iyi, sağlam VCS. (Ben hiçbir şekilde en iyi düşünmek olmaz, ama güzel ekstralar var.)
  2. Visual Studio ile entegre olan yerleşik görev ve hata izleme, odaklanmış kalmamı ve tek bir yerde ne üzerinde çalışmam gerektiğini bilmemi sağlıyor (otomatik olarak bir hataya veya göreve bir check-in uygulamak ve bunu kapatmak oldukça iyi, ancak bunu yapmak için diğer sistemler/Eclipse/etc için eklentiler edinin.)
  3. Görevleri/hata izleme/projeleri doğrudan Project Server'a entegre eder, böylece proje planlarını veya zaman çizelgelerini nadiren güncel tutmam gerekir. Project Server'daki Project güncelleştirmeleri otomatik olarak görebilmem için görevler olarak TFS'ye ve Visual Studio'ya otomatik olarak filtre uygular.
5
Ryan Hayes

Uzun geçmişimde çok sayıda sürüm kontrol sistemi kullandım:

  • RPPT Delikli Kağıt Bant Ruloları). Bir ayakkabı kutusunda. Şaka yapmıyorum.
  • PVCS - (Polytron Versiyon Kontrol Sistemi). Kullandığım ilk gerçek VCS.
  • SCCS - çok uzun zaman önce, bu konuda son derece iyi veya kötü bir şey hatırlamıyorum.
  • RCS - Diğerlerinin de belirttiği gibi, terli eşek toplarını emmeyi tercih eder.
  • CVS - 2'den fazla programcı ile kullanıldığında sadece bir acıydı. en iyi özellik: rcs2cvs.
  • VSS - tüm deponuzu bozduğu salı günleri hariç çalışır.
  • Performans - arabamdan daha pahalı. VCS kendisi kabul edilebilir, ancak onu kullanmak her yönünü kontrol dickhead BT çocuklar asla benim "tercih edilen" listemde inecek.
  • SVN - dallanma ve birleşme bir kaltaktır, ancak genel olarak öncekilerden daha iyidir. İnceleme bekleyen çok sayıda küçük olağanüstü değişikliklerle çok iyi değil.
  • Mercurial - bununla ilgili ne kadar az deneyimim var, beğendim. Bir sonraki projemde deneyebilirim.
  • Git - hiç kullanma fırsatı bulamadı.

Bir çift dehşet olmasına rağmen, çoğu "iyi" idi. Yoluma çıkmadılar. Bir araç olduğu sürece --- (hayatımı önemli ölçüde zorlaştırmaz, umrumda değil.

Gerçek olan, her birinin güçlü ve zayıf yanlarını anlamaktır. Hedef ortamı anlayın:

  • dağıtılmış veya yerel
  • küçük takım veya büyük
  • barındırılan vcs hizmeti ya da değil
  • diğer araçlara kolay entegrasyon

Joel ayrıca önemli bir gözlemle ortaya çıktı: Aracı ve gerçek kullanım modelini öğrenin. Mercurial'ın Subversion gibi davranmasını sağlamak için kasıtlı olarak mücadele etti.

4
brettmjohnson

Ofisimde kullandığımız yeni bir sistem Plastik SCM (http://www.plasticscm.com/). Küçük ekibimiz için çok iyi çalışıyor ve kaynak yönetiminin her yönü üzerinde bize büyük bir kontrol sağlıyor.

2
Tom A

SCC .

Veya son 38 yıldır bir mağara yaşamamışsanız, CSSC .

Cidden, şirketim SCCS tabanlı bir tür sahte DVCS olan TeamWare kullanıyor.

Hayır, şaka yapmıyorum.

Sun, birkaç yıl önce TeamWare'den Mercurial'a geçti. Şimdi Java neden bu kadar yavaş hareket ediyor gibi göründüğünüzü anlamalısınız.

1
Geoffrey Zheng

MPW: Çabalarıma rağmen gerçekten bir inceleme yapamıyorum.

Bu, lisede programlama öğrenirken geri döndü ve sahip olunacak tek gerçekten ücretsiz C++ derleyicisi, bir Zip diskinde tuttuğum ve laboratuvarda Performa'nın mevcut olduğu herhangi bir yere attığım Macintosh Programlama Çalışma Tezgahıydı.

MPW düzinelerce araçla geldi (hiçbiri yeniden düzenlenmedi, bu ayrı bir indirme idi) ve bunlardan biri bir sürüm kontrol yardımcı programıydı. Tek bir metin satırı içeren küçük bir pencere açıldı ve projelerinizi veya dosyalarınızı sürükleyip bırakacaktınız. Ben her zaman büyük dokümanlar var gibi göz önüne alındığında, alışılmadık hiçbir belge vardı, olağandışı, ve bu yüzden onu nasıl kullanılacağını hiç çalışmadım.

Bu benim VC'li ilk fırçamdı ve uzun süredir son fırçamdı. Şimdi git'i her şey için kullanıyorum.

RCS - Revizyon Kontrol Sistemi

Solo kodlama çok kolay.

0
Jé Queue

Visual SourceSafe kullandım ve nefret ettim, ama hiç yoktan iyiydi, ama çok değil. Son birkaç yıldır, programcı Jim Voris tarafından yazılan, sahip olunan ve desteklenen Qumasoft.com tarafından QCVS adı verilen bir şey kullandı. Basit gui, ucuz fiyat, iyi destek.

Sadece işi yapar.

0
crosenblum

ClearCase değil, en azından bir Unix/Linux sistemi için (belki Windows ile yükleyici daha kolaydır). ClearCase sunucumuzu yükseltmek yerine yeni bir araç olan Perforce'yi öğrenmek benim için daha kolaydı.

Şu anda iş yerinde Perforce kullanıyorum ve beğendim ama en iyisi olup olmadığı hakkında hiçbir fikrim yok. Komut satırı ortamını ve Perforce Server'ı kurmak biraz gariptir, ancak Visual Client'ı kullanmak oldukça kolaydır. Kullanıcıların günlük görevler için oldukça kolay bir zaman geçirdiğini düşünüyorum; sadece ilk kurulumda biraz çalışma gerektirir.

0
Chance