Şirketler, farklı sürüm kontrol sistemleri kullanan diğer şirketleri satın alırlar.
Subverson-GIT köprüsünün kullanılması veya hatta sadece bir aracın diğerinin üzerinde kullanılmasına karar verilmesi gibi sistemlerin nasıl entegre edileceği ve sistemler arasında nasıl geçiş yapılacağı konusunda ortak bir bilgelik var mı?
İnsanlar, yazılım geliştirme konusundaki "Joel" testine eşdeğer bir karar kümesi için bir dizi kriter kullanıyor mu?
Yanıtlar:
Göç sorusunu çeşitli göçlerin kişisel deneyiminden cevaplamak için:
Yazılımın güncel sürümünü temel kaynak olarak yeni kaynak kontrol sistemine yerleştirmekten ve oradan çalışmaktan korkmayın.
Zamanın büyük çoğunluğu tarihe ihtiyacınız olmayacak. Bu, entegrasyon sırasında gerçekleştirilecek daha az görev ve yanlış gitmek için daha az şey olduğu anlamına gelir.
Aktif olarak geliştirilen dosyalar / projeler yakında yeni bir tarih yaratacaktır. Bu nedenle, neden bir değişiklik yapıldığını öğrenmeniz gerektiğinde, tarihin yakın zamandaki bir değişiklik olacağı için mevcut depoda olması ihtimali vardır.
Taşıma işleminden önce kararlı olan dosyalar / projeler, taşıma işleminden sonra sabit kalmalıdır (her şey eşittir), böylece geçmişe bakmanıza gerek kalmaz. Böyle eski bir dosya / projedeki bir hatayı araştırmak zorunda olsaydık, geçmişe sahip olmanın gerçekten faydası olmadığını gördük. Eski depoyu yılda 6 ay boyunca sakladığınız sürece bu gibi durumlarda referansınız olacaktır.
Yönetimsel açıdan, bu temel olarak bir sorudur:
Proje tarafında, bu aynı zamanda bir sorudur:
Ücretsiz ya da değil, "özgür" yazılım hatırlıyorum "özgür konuşma" (özgür olanı seçmek ve dağıtmak için özgür) gibi "özgür bira" değil, (hala sunucuda çok para mal olacak) , yedekleme, yönetim, destek, ...)
Yukarıdaki kriterler, hangi VCS'nin tutulacağını, neyin terk edileceğini belirlemeye başlar.
Ancak ikinci durumda, dikkate almanız gerekir:
Farklı sistemleri entegre etmeye gerçekten ihtiyacınız var mı? Ekibimizde, her proje kendi deposunda yaşıyor ve böylece tarihleri birbirinden bağımsız. Burada, aralarında bağımlılıklar olsa bile, yıkım altındaki bazı projelerle ve civa altındaki başka projelerle çalışmak konusunda hiçbir sorunumuz yok.
Bir VCS'den diğerine geçmeyi seçerseniz, kullanılabilir dönüştürme araçlarına bakın. Deneyimlerime göre, projelerin geçmişini bırakmak için teknik bir neden yok.
Sanırım soruda ve diğer cevaplarda örtük olan bir şey anladım. VCS'nin bağımlılıkları yönetmek için de kullanıldığı gerçektir. svn:externalsBir repo'yu (bağımlılık) diğerine entegre etmek gibi VCS özelliklerini kullanmanın oldukça yaygın olduğunu biliyorum .
Ekibimizin 2 farklı sistemimizi köprülemeye (veya entegre etmeye) ihtiyaç duymadığını (teknik) nedeninin, bağımlılıkları yönetmek için ayrı bir aracımız olması olduğunu düşünüyorum. Depomuz birbirini tanımıyor.
Çok iyi cevaplar. Düşünülmesi gereken bir diğer şey de, takım üyelerinin VC'yi değiştirmeyi düşünmekten kaçınmasına izin vermemek çok önemli. Göç, bir öğrenme eğrisi vb. İle ilgili bir aksaklık olacaktır, ancak çok fazla problemleri varsa, yetenek ve / veya işbirliği seviyelerini sorgulamaları gerekir.