Checkin ve checkout arasındaki fark nedir?

14

Yazılım Yapılandırma Yönetimi'nde yeni olan öğrencilere SCM dersleri verirken, " What's the difference between checkin and checkout?" gibi bir soru ortaya çıkar .

Ve bunun bir varyasyonu, bu öğrencilerin bu SCM kavramları hakkında karıştırılmalarıdır (onları başka bir yol olarak anlıyorlar).

Öyleyse bu önemli SCM kavramını bu tür izleyicilere açıklamak için ne tür bir metafor kullanabilirsiniz?

terminology scm

— Pierre.Vriens
kaynak

ödeme = kilit; checkin = kilidini aç; İşlemi gerçekleştirdiğiniz dalda söz konusu nesneyi düzenlemek için özel kilit alırsınız.

— Jiri Klouda

8

Bir şeyi kimseye açıklamak için (umarım) zaten aşina oldukları bir şeyle karşılaştırmayı deneyin.

Bu yüzden böyle bir soruyu şöyle cevaplıyorum:

Kalacak bir yere (otel, tatil köyü, vb.) Varmak olarak düşünün:

çok ilk (size geldiğinde) yapmanız şey etmektir checkin.

yaptığınız en son şey (ayrılırken) yapmaktır checkout.

Yazılım bileşenlerine değişiklik uygulamak istediğinizde de benzer bir SCM konsepti geçerlidir, ancak bunun tersi de geçerlidir :

çok ilk (eğer başlattığınızda) yapmanız şey etmektir checkout(veya ödünç gibi düşünebilirsiniz).

çok son (bitince) yapmanız şey etmektir checkin(veya geri veriyor gibi düşünebilirsiniz).

Not : Bu, merkezi sistemler için geçerlidir (ana bilgisayar ortamlarında kullanılanlar gibi ...). Git gibi sistemlerde " checkout" kavramı tamamen farklı bir anlama sahiptir (IMO da bu sistemlerde her iki kavram hakkında da neredeyse hiç karışıklık yoktur).

— Pierre.Vriens
kaynak

Belki de kod bir otel odasından ziyade bir kütüphane kitabı gibidir?

— Toby Speight

Bu oldukça naif, sıradan bir cevap. On yıl boyunca kaynak kontrol sistemlerinin iç kısımlarında çalıştım, bu yüzden sorunuza biraz daha derinlemesine bir cevap ekledim.

— Jiri Klouda

6

"Checkin" ve "checkout" terimlerinin SCM sisteminin türüne bağlı olarak farklı anlamları olduğuna dikkat etmek önemlidir.

TFVC, Subversion ve Clearcase gibi merkezi sistemlerde "özel" ödeme yöntemleri kullanılır. Bu, Pierre'in kitap ödünç verme metaforuna benziyor, burada sadece bir kullanıcının bir seferde bir dosyayı teslim alması mümkün.

Git gibi dağıtılmış sistemlerde "checkout" komutu vardır, ancak bu tamamen farklı bir şey anlamına gelir. git checkoutyerel bir havuzla çalışırken dallar arasında geçiş yapmak için kullanılır.

— Dave Swersky
kaynak

Dave'in dağıtılmış sistemler hakkında iyi bir anlamı var! Aslında bu yüzden ilk başta kendim (GIT hakkında ilk öğrendiğimde) çok karışıktı. Cevabınızı geçersiz kılmak için (sorumu uyarlayarak), cevabımı biraz açıklığa kavuşturmak için rafine ettim.

— Pierre.Vriens

Açıklığa kavuşturmalıyım: git checkout, depodaki nesneleri kontrol etmek için kullanılır. Bu bir şube veya tek bir dosya olabilir.

— Dave Swersky

4

Merkezi sistemler için, bunu teknik bir kütüphane gibi düşünün. (bu varsayımsal kütüphanenin nasıl işlediğine dair bir hayal gücü olabilir ...)

Bir dokümanın yazarıysanız checkout, kütüphane kopyalayabilir, değişiklik yapabilir check it back in, dünyanın görmesi için kütüphaneye iade edebilirsiniz .

Bu, kütüphanenin dijital kopyaları varsa bir sorun haline gelebilir ve ben checkoutbir belge, başka biri de checks outbir belge, ikimiz de değişiklik yaparız, çözülmesi zor olabilecek bir çatışma (birleşme çakışması) olacaktır. O zaman bunun için ilk "düzeltme" özel checkoutişlevsellik olduğunda ...

Kritik birleştirme çatışma konunun şansı (insanlar sisteminin farklı bölümlerini çalışıyor olacak) azalır büyük projeler için Tabii böylece checkout/ checkinneredeyse kadar gerekli değildir. Ve tasarımla dağıtılmış sistemler, diğer bir çok avantajla birlikte iyi birleştirme işlevselliği gerektirdiğinden, bu konsept git ve diğer DVCS'de gerçekten mevcut değildir.

— timin
kaynak

Bu ona bakmanın başka bir yolu. Deneyimlerime rağmen, "çatışmalar" ve "birleşme" gibi şeyler eklemenin iyi bir fikir olduğunu düşünmüyorum (eğer henüz ödeme ve check-in ile rahat hissetmiyorlarsa).

— Pierre.Vriens

Adil, ben ekledi çünkü onun ödeme / check-in aklıma var ana nedeni. Ve bu kavramın gerçekten ne işe yaradığını bilmiyorsanız, bir kavramın kavranmasının ekstra zor olduğunu hissedin.

— Timin

2

Ana konu olarak SCM deposu ile '

ödeme değişiklikleri oluyor dışarı (yerel çalışma dizine) yerel veya uzak deposundan.
İade değişiklikler geri koyuyor içine (yerel çalışma dizininden) yerel veya uzak depo.

— hlovdal
kaynak

Bu cevap için Merci de . Bu gerçekten açıklamanın bir yolu, yine de bir çeşit "metafor" düşünebilir miyim merak ediyorum (sorumda olduğu gibi). Örneğin, yerel ya da uzak bir deponun gerçekte ne olduğu hakkında bir fikri olmayan, öğreteceğiniz birine açıklamak .

— Pierre.Vriens

Doğru, eğer bir havuzun ne olduğu hakkında hiçbir fikri yoksa, check-in ve check-out'ı öğretmeye çalışmak anlamsız olacaktır. Şimdi, genel olarak kaynak kontrolü metaforu için finansal muhasebe / defter tutma ile karşılaştırabilirsiniz. Temelde varlıkların değerindeki değişiklikleri izler. Çok büyük gruplar olmamasına rağmen (örneğin, "Pazartesi günü yapılan tüm masraflar"), tek tek değişiklikleri veya değişiklik gruplarını (örneğin, taksi bileti + otobüs senedi + tren bileti + ... yerine "A'dan B'ye Seyahat") kaydedersiniz. Benzer şekilde bir havuz, kaynak kodu değişikliklerini (bireysel veya çok büyük olmayan gruplar) izler.

— hlovdal

1

Checkout , bir depodaki bir nesne dalını değiştirmeye yönelik özel bir kilittir.

Checkin , özel kilidin bir sürümüdür.

En küçük dallanma biriminin ne olduğuna bağlı olarak iki tür kaynak kontrol sistemi vardır.

1) Havuz başı dallanma başına (CVS, SVN, GIT, Perforce, vb.)

Deponun tamamını dalladığınız ürünlerde, ödeme genellikle tüm deponun yerel kolunda (kopyasında) değişiklikler oluşturur veya etkinleştirir. Bu ürünler giriş genellikle kullanılmaz ve bir parçası haline işlemek , aynı anda işlem, ödeme lokal uygulanması, uzaktan dalın yama ve kontrol ederken tek bir işlemde uzak dalın. Sen yok kontrol ediyorum kalıcı teslim olarak yerel şube. (Not: GIT'de uzak şubeye bağlı kalmazsınız, yerel taahhüdünüzü ona aktarırsınız. Kesinlikle sözdizimsel fark. )

2) Nesne dallanması başına (ClearCase, AccuRev, Oracle ADE)

Vb dizinleri, dosyaları gibi tek tek nesneleri şube ürünlerde kavramı kasada ve check şube başına nesne başına geçerlidir. Nesneyi ödeme ile değiştirmek ve iade etme ile serbest bırakmak için nesneyi kilitleyeceksiniz . Bu ürünlerde genellikle kilitlerin kimsenin çalışmasını engellemediği özel bir dalda çalışırsınız ve yerel dalınızın paylaşılan bir dalda birleştirilmesi sırasında, nesneler ayrıca parça dalında (ana, ana, özellik dalı vb. ) birleştirme çakışmaları giderilir ve paylaşılan dalda nesne denetlenir . Bu, birden çok kişinin aynı nesneyi değiştirmedikleri sürece paylaşılan şubeye aynı anda "taahhütte bulunmasına" olanak tanır.

— Jiri Klouda
kaynak

Hey Jiri, cevabınız için merci. Bahsettiğiniz 2 çeşit için katılıyorum. Ama anabilgisayar dünyasındaki SCM araçlarında (tecrübelerimden kaynaklanıyordu) biri "kilitlemeyi" dikkate almıyor ... Cevabınıza 3. tür eklemenin bir yolunu düşünebilir misiniz?

— Pierre.Vriens

Bu kategorilere uymayan bir ürüne örnek verebilir misiniz? Ya 2'den hangisine uyduğunu söyleyebilirim ya da gerçekten varsa, bir üçüncü ekleyebilirim. Ödeme ve iade, bir şube üzerinde değişiklik yapma hakkını veren ve serbest bırakan işlemlerdir. Bu nedenle, bir ürün dalının (tüm depo veya bireysel nesneler) ne olduğu konusunda bölümleme bu soru için doğaldır. Arada bir şey olup olmadığını bilmiyorum, ne olurdu? Performans ve Subgit'de olduğu gibi alt ağaçların dallanması temelde ilk kategoridir. Kilit 'münhasır hakkı' için farklı bir isimdir.

— Jiri Klouda

BTW Daha önce de belirtildiği gibi kütüphane metaforu gerçekten iyi. Bir kitaba göz attığınızda, ona özel bir hak elde edersiniz. Onu eve götür ve istediğin gibi yap. Kitabı okuyun, hatta kenar boşluklarındaki notları karalayın ve kitabı teslim alırken hiç kimse kitabı değiştiremez. Bazı sayfalarını kaldırmak veya bazı satırları vurgulamak gibi. Kitabı kontrol ettiğinizde, insanlar kütüphanecinin dikkatli gözünün herhangi bir modifikasyona (vandalizm) izin vermediği veya kontrol edip eve götürdüğü kütüphanede okuyabilir. Bu kitaptaki değişiklikleri serileştirir.

— Jiri Klouda

Analojiyi devam ettirmek için, kütüphanenin farklı bir dalında, aynı kitap farklı modifikasyonlarla olabilir veya tamamen değiştirilmemiş veya hiç değişmemiş olabilir. Birisi aynı anda orada kontrol edebilir (yani ödeme şube başına). Şimdi orijinal yazar 2. baskıda çalışıyor, tabiri caizse bir ana dal. Birden çok şubeden notlar okuyabilir, bunları birleştirebilir, ana şubeye ve 2. baskıyı kontrol edebilir. Her kütüphane dalı 2. baskı satın alarak kopyalarını yenileyecektir. 1'ini atabilir veya yine de faydalı notları kenar boşluklarından yeni sürüme kopyalayabilirler.

— Jiri Klouda