En sevdiğiniz sürüm kontrol sistemleri hangileridir? [kapalı]

Bu, kuruluşun ihtiyaçlarına göre açıkça değiştiğinden, "en iyisini" belirlemeye yönelik gerçek bir girişimden çok bir tartışma sorusudur. Kategoriler arasında farklı sistemler lehine olan argümanları daha merak ediyorum (merkezileşmiş vs dağıtılmış, açık vs özel mülk, vb.).

Sence en iyi sürüm kontrol sistemi hangisidir?

cıvalı

Kodu dallama ve birleştirme konusundaki karmaşık yeteneği nedeniyle, kullandığım en iyisidir. Bütün DVCS paradigması çok anlamlı. Git'i kullanmadım, ama sanırım aynı zamanda hak ediyor.

Git

Git harika ve özellikle açık kaynaklı projeler üzerinde çalışan herkese tavsiye ediyorum: Git projesindeki bir projeye küçük, bir seferlik bir değişiklik yapmak, özellikle de GitHub'da barındırılıyorsa, e-posta ile uğraşmaktansa çok daha kolaydır. SVN ile posta yamaları.

Windows kullanıcıları için büyük bir uyarı: Git'in Windows araçları, kesinlikle kullanılabilir olsa da, çizilmeye pek de uygun değil. Bir süre Windows kullanmaya zorlandığımda, Mercurial'in Windows arayüzünü Hg-Git entegrasyon aracıyla denedim, böylece Git depolarımı kullanabildim ve kullanımı çok daha kolay buldum.

Uyarı: Bu yazıdan beri Mercurial'ı buldum ve SVN'den çok daha iyi seviyorum. Bu yüzden bu yazı Pro SVN yorumları ve genel DVCS karşıtı yazılarla biraz güncel değil, ancak anti-git olayları hala geçerli

Git'in üzerindeki SVN 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 tada bıraktı.

Küçük bir dükkanda staj yaparken Windows'ta git ile tanıştırıldım. Hemen Github ile çalışabilmesi için harcadığı işi hemen fark ettim. İlk önce, bir ssh özel anahtarı oluşturmak, genel anahtarı Github'a yapıştırmak, sonra yarışmaya çıkarmak ve basmak istediğimde özel anahtarımı açmak zorunda kaldım, ki bu çok can sıkıcıydı.

Ve ben hiçbir zaman tüm depoyu aşağıya çekmekten hoşlanmadım. Asla büyük bir şeyle çalışmadığımı itiraf edeceğim, ancak tüm depo ve revizyonları HD'mde olsa, KDE'nin Git'teki deposunu indirmekten korkardım.

Sonra bir taahhüt yapmak için kafa karıştırıcı bir süreç vardı. TMK, ilk önce yapmak istediğim tüm dosyaları "aşamalandırmak" zorunda kaldım (birçok dosyaya sahip olduğunuzda emildi, her şeyi aşamalandırmak için el ile komutu bulmak için biraz zaman aldı), sonra işlemi yapın, sonra ana ekrana basın. repo (neden bu ayrı bir işlem ?!).

Ayrıca (!) Çok yardımcı olmayan taahhüt verisine sahiptiniz. Ah, bak bu 14f74433245ae17aeeaa ağacının bir parçası 2167a4934d0a4a7db0de ve ebeveyn d7042abb4821d3faf600. Bu ne anlama geliyor? İşleri çok hızlı bir şekilde çözebilmeliyim ve bazı tuhaf belgelere başvurmam gerekmeyecek.

Belgelerden bahsetmişken, en azından onu kullanırken, her şey linux man dosya biçiminde, IE kafa karıştırıcı ve bana işe yaramaz görünüyordu. Dokümanlarda çok fazla yardım bulamadım ve google'a başvurdum.

Taahhütlerde sevmediğim tek şey sürüm numaralarının olmamasıydı. Şimdi bunun git tasarımı yüzünden olduğunu biliyorum, ancak herhangi bir yazılımın sürüm numarasına ihtiyacı var. İşaretçinin "1.8.6 olarak değiştirildi sürümü" veya benzeri bir şey söyleyerek ortaya çıkacağını hala hatırlıyorum, ancak yine de yapı numaraları yapamıyorsunuz. 1.8.6.5164 sürümüne sahip olmak benim için (son kısım revizyon numarasıdır) bana 1.8.6'dan çok daha fazlasını ve küçük bir şeyin değiştiğini söyleyen bir notu anlatıyor, dene

Yazılıma özgü olan Windows'taki temel program, korkunç bir arayüz olan msysgit'tir. Bana birkaç kez kilitlendi, korkunç bir arayüze sahipti ve CLI-GUI entegrasyonu en iyisi değildi. Çevremdeki komut satırı bağımlıları gui'den daha çok nefret ediyordu.

Şimdi SVN'ye bakalım. Ve ben Windows'tayken ve özellikle TortoiseSVN ve Google Code gibi bir google hesabım olduğundan.

Öncelikle, depodaki her şeyi yapmak için komple kabuk entegrasyonu (ve sizin için linux insanlar için RabbitVCS aynı şeyi yapar), ana GUI'ye gerek yok. Bir havuz almak bir ödeme yapmak kadar kolaydır, hiçbir SSH'ye gerek yoktur (Github'un çekimler için SSH gerektirip gerektirmediğini hatırlayamıyorum) ve HD'nizde oturmuş bütün bir taahhüt yok.

Taahhüt etmek aşırı derecede kolaydır, çünkü SSH veya evreleme gerekmez. Sadece çok yararlı olan tüm dosyaları seçerek msysgit versiyonumda mevcut olmayan seçeneği seç, bir onay mesajı yaz ve onaylamayı tıkla. Google Kodu daha sonra giriş bilgilerinizi (çoğu müşterinin depoladığı) ve yaptığınız işlemi ister. Basit, kolay ve SSH yok

Sürüm numaraları? Bazı kolay kodlarla, tüm ödemelere sürüm numarası ve taahhüt numarası ekleyebilirsiniz; bu da işleri çok daha kolay hale getirir. Ayrıca, gerçekten değişiklik gösteren kullanılabilir sürüm numaraları elde edersiniz, örneğin 1.8.6.5165, 1.8.6.5164'ten daha yenidir.

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

Birleşme, karşılaştıramayacağım başka bir şey. Üzerinde çalıştığım bir dosyada bir başkası değişiklik yaptığında ama hiçbir zaman SVN'de olmadığında Git'te bir kez yapmak zorunda kaldım.

Hangisini tavsiye ederim? Eh, büyük takımlarda, git, doğrusal olmayan gelişim döngüsünde, avantajlarına sahiptir. Başka bir projede 4 programcının ayrı dallarda başladığını, ardından tüm kodu bir şekilde son ana dalda işleyen çok garip şekillerde birleştirdiğini gördüm. 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, SVN en iyisi olacaktır, çünkü Gits özelliklerinin çoğu kullanılmaz ve yalnızca olumsuz kısımlarını alırsınız. Sadelik böyle güzel bir şey

Q4TD'den şu alıntı, benim için hemen hemen özetliyor:

“Denene 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 genellikle TortoiseSVN kullandığım Windows komutundan farklı olarak komut satırını kullanırım). En büyük avantaj: .svnher klasörde alt klasör yok, sadece .hgüst seviyede.

Güncelleme: Alex'in "git'in neden işe yaramadığını ve Mercurial'ın nasıl daha iyi çalıştığı hakkında daha fazla şey söyleyin" yorumundaki isteğine cevaben:

Ben Git öyle demezdim değil benim için çalışmalarını fakat Murcurial daha iyi IMO çalışır.

Özetle, bu Mercurial:

ve bu Git:

Ve Mercurial'ın çoğu geliştiricinin ihtiyaç duyacağı her şeyi yapacağını, günlük işlerin nasıl yapılacağını bulmak için kılavuza bakmak zorunda kalmayacağını iddia ediyorum.

Kuşkusuz, Git'i yalnızca ara sıra kullandım, ancak programlama topluluğu, özlü ve şık oldukları için kısmen Ruby ve Python gibi diller üzerinde gagalaşmaya devam ederken, Git bir deve komitesi tarafından tasarlanan bir deve gibi hissediyor.

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

Güncelleme 2: Yeni rastladığım başka bir apropos tweet'i :

“Dalların bir Hilbert uzayının altmanifoldlarını haritalayan homeomorfik endofunctors olduğu temel fikrini aldıktan sonra Git daha kolaylaşır.”

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

Birden fazla farklı merkezi versiyon kontrol sistemi ve birden fazla farklı dağıtılmış versiyon kontrol sistemi kullandım. Ve tereddüt etmeden kimsenin asla kendilerine CVCS vermemesi gerektiğini söyleyebilirim.

Hangi DVCS'yi seçtiğinize dikkat etmiyorum (özel favorim Git), ancak lütfen kendinize bir iyilik yapın ve bir DVCS kullanın. Birincisi: çok daha esnek olacaksın. DVCS'ler bir CVCS iş akışını önemsiz bir şekilde taklit edebilir (yalnızca depoya asla çatal yapılamaz ve yerel depolarınıza yalnızca bağımsız bir çatal yerine bir chache olarak bakabilir), ancak görüşme imkansızdır. Ve mantıklı iken, bu öykünme yapıyor gereken bazı ek yükü taşımak (ve gerçekten de etmez), ben hala daha kolay kullanım için ben kullandım CVCSs hepsinden daha (çok daha fazla ölçülebilir nedeniyle yerel önbelleğe alma saymıyorum) bulabilirsiniz.

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

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

Fosil , dağıtılmış bir sürüm kontrolü, hata izleme ve SQLite veritabanında depolanan wiki projesidir.

Takım Temel Sunucusu

Çünkü:

1. Güzel , sağlam bir VCS . (Hiçbir şekilde en iyisini düşünmezdim, ama güzel ekstraları var.)
2. Visual Studio'ya entegre olan yerleşik görev ve hata izleme özelliği bana odaklanmamı ve tek bir yerde neyin üzerinde çalışmam gerektiğini bilmeme yardımcı oluyor (otomatik olarak bir hata veya göreve check-in yapmak ve onu kapatmak oldukça iyi. Bunu yapmak için diğer sistemler / eclipse / etc eklentilerini edinin.)
3. Görevleri / hata izlemeyi / projeleri doğrudan Project Server'a entegre eder, bu yüzden nadiren proje planlarını veya zaman çizelgelerini güncel tutmak zorunda kalmam gerekir. Project Server'daki Project'teki güncellemeler, otomatik olarak görmem için otomatik olarak TFS'ye ve Visual Studio'daki görevler olarak filtrelenir.

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

• RPPT - (Delikli Kağıt Bantın 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ü hiçbir şeyi hatırlamıyorum.
• RCS - Diğerlerinin de belirttiği gibi, terli eşek toplarını emmeyi tercih ederim.
• CVS - sadece 2'den fazla programcı ile birlikte kullanıldığında bir acıydı. en iyi özellik: rcs2cvs.
• VSS - Salı günleri hariç tüm depolarınızı bozduğunda işe yarar.
• Performans - arabamdan daha pahalı. VCS'nin kendisi kabul edilebilir, ancak kullanımı her yönden kontrol eden ikiyüzlü BT çalışanları asla "tercih edilenler" listeme girmeyecek.
• SVN - dallanma ve birleşme bir fahişedir, fakat genel olarak öncekilerden daha iyidir. Gözden geçirmeyi bekleyen çok sayıda küçük olağanüstü değişiklik ile çok iyi değil.
• Mercurial - Bununla ne kadar deneyim yaşadım, hoşuma gitti. Bir sonraki projemde deneyebilirim.
• Git - hiç kullanma fırsatı bulamadım.

Bir çift dehşet olmasına rağmen çoğu "iyiydi". Benim yoluma çıkmadılar. Bir araç hayatımı önemli ölçüde zorlaştırmazsa , gerçekten umursamıyorum.

Gerçek olan, her birinin güçlü ve zayıf yönlerini 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 veya
• diğer araçlara kolay entegrasyon

Joel ayrıca önemli bir gözlemle ortaya çıktı: Aracı ve gerçek kullanım modelini öğrenin. Mercurial'ı Subversion gibi davranmak için güçlü bir şekilde mücadele etti.

Ofisimde kullandığımız yeni bir sistem Plastic SCM'dir (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.

SCCS .

Veya, son 38 yıldır mağarada yaşamıyorsanız , CSSC .

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

Hayır, şaka yapmıyorum.

Sun sadece birkaç yıl önce TeamWare'den mercurial'a geçti. Şimdi Java'nın neden bu kadar yavaş hareket ettiğini görünmelisiniz.

MPW: Gayretlerime rağmen gerçekten bir inceleme yapamam.

Lisedeyken programlama öğrenirken geri döndüm ve sahip olduğum tek gerçekten ücretsiz C ++ derleyicisi, bir zip diskte tuttuğum ve laboratuarda hangi Performansı kullanabildiğimin üzerine çıkarılan Macintosh Programlama Tezgahıydı.

MPW düzinelerce araçla geldi (hiçbiri sıfırlanmadı, bu ayrı bir indirme oldu) ve bunlardan biri sürüm kontrol yardımcı programıydı. Tek bir satır metin içeren küçük bir pencere açıldı ve projelerinizi veya dosyalarınızı sürükleyip bırakacaktınız. Keşfedebileceğim bir belge yoktu, başka her şeyin harika dokümanları varmış gibi göz önüne alındığında olağandışıydı ve bu yüzden onu nasıl kullanacağımı hiç düşünmedik.

Bu benim VC'deki ilk fırçamdı ve sonuncusu da uzun süre kullanıldı. Şimdi Git'i her şey için kullanıyorum.

RCS - Revizyon Kontrol Sistemi

Yalnız kodlama çok kolay.

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

Şu anda iş yerindeki Performance'ı kullanıyorum ve hoşuma gidiyor ancak en iyisi olup olmadığına dair hiçbir fikrim yok. Komut satırı ortamını ve Performans Sunucusunu ayarlamak biraz zordur, ancak Visual Client'ı kullanmak oldukça kolaydır. Kullanıcıların günlük işler için oldukça kolay zaman geçirdiğini düşünmeyi seviyorum; bu sadece ilk kurulum biraz çalışma gerektiriyor.

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

Sadece işi yapıyor.