Neyse ki, hala CVS kullanmak zorunda kalan bizler için git, tam olarak yapmak istediğiniz şeyi yapmak için oldukça iyi araçlar sağlıyor. Önerilerim (ve burada $ work'de ne yapıyoruz):
İlk Klonun Oluşturulması
git cvsimportCVS revizyon geçmişini bir git deposuna kopyalamak için kullanın . Aşağıdaki çağrıyı kullanıyorum:
% git cvsimport -d $CVSROOT -C dir_to_create -r cvs -k \
-A /path/to/authors/file cvs_module_to_checkout
-ASeçenek isteğe bağlıdır ancak CVS ithal en bakmak senin düzeltme geçmişini hale getirmeye yardımcı olur daha git-benzeri (bkz man git-cvsimportBu ayarlandıktan konusunda daha fazla bilgi için).
CVS deposunun boyutuna ve geçmişine bağlı olarak, bu ilk içe aktarma ÇOK uzun bir zaman alacaktır. Gerçekte bir şey olduğuna dair içinizin rahat olmasını istiyorsanız yukarıdaki komuta -v ekleyebilirsiniz.
Bu işlem tamamlandıktan sonra, masterCVS'nin HEAD'ini yansıtması gereken bir şubeye sahip olacaksınız ( git cvsimportyarı bitmiş bir işlemi yakalamaktan kaçınmak için varsayılan olarak son 10 dakikalık taahhütleri yok sayması dışında). Daha sonra git log, tıpkı baştan beri git kullanıyormuş gibi, deponun tüm geçmişini incelemek için and friends komutunu kullanabilirsiniz .
Yapılandırma Tweaks
Gelecekte CVS'den artan ithalatı (ve dışa aktarımı) kolaylaştıracak birkaç konfigürasyon ince ayarı vardır. Bunlar git cvsimportman sayfasında belgelenmemiştir, bu yüzden önceden haber verilmeksizin değiştirilebileceklerini sanıyorum, ancak FWIW:
% git config cvsimport.module cvs_module_to_checkout
% git config cvsimport.r cvs
% git config cvsimport.d $CVSROOT
Bu seçeneklerin tümü komut satırında belirtilebilir, böylece bu adımı güvenle atlayabilirsiniz.
Artımlı İthalat
Sonraki git cvsimportilk çağrıdan çok daha hızlı olmalıdır. Bununla birlikte, cvs rlogher dizinde (yalnızca dosya içerenler bile Attic) bir işlem yapar, böylece yine de birkaç dakika sürebilir. Yukarıda önerilen yapılandırmaları belirttiyseniz, yapmanız gereken tek şey çalıştırmaktır:
% git cvsimport
Yapılandırmalarınızı varsayılanları belirtecek şekilde ayarlamadıysanız, bunları komut satırında belirtmeniz gerekir:
% git cvsimport -r cvs -d $CVSROOT cvs_module_to_checkout
Her iki durumda da akılda tutulması gereken iki nokta:
- Git deponuzun kök dizininde olduğunuzdan emin olun. Başka bir yerdeyseniz
cvsimport, tekrar sonsuza kadar sürecek taze bir şeyler yapmaya çalışacaktır .
masterDeğişikliklerin yerel / konu şubelerinizle birleştirilebilmesi (veya yeniden düzenlenebilmesi) için şubenizde olduğunuzdan emin olun .
Yerel Değişiklikler Yapmak
Pratikte, şubelerde her zaman değişiklik masteryapmanızı ve yalnızca bu değişiklikleri CVS havuzuna geri aktarmaya hazır olduğunuzda birleştirmenizi öneririm . Şubelerinizde istediğiniz herhangi bir iş akışını kullanabilirsiniz (birleştirme, yeniden sıralama, ezme, vb.), Ancak elbette standart yeniden ödeme kuralları geçerlidir: başka biri değişikliklerini şubenize dayandırıyorsa yeniden ödeme yapmayın.
Değişiklikleri CVS'ye Aktarma
git cvsexportcommitKomut tek CVS sunucusuna dışarı işlemek ihracat sağlar. Tek bir kaydetme kimliği (veya içinde tanımlandığı gibi belirli bir kaydetmeyi tanımlayan herhangi bir şey) belirtebilirsiniz man git-rev-parse. Daha sonra bir fark oluşturulur, bir CVS kontrolüne uygulanır ve ardından (isteğe bağlı olarak) gerçek cvsistemciyi kullanarak CVS'ye işlenir . Konu dallarınızdaki her mikro kaydı dışa aktarabilirsiniz, ancak genel olarak güncel bir birleştirme taahhüdü oluşturmayı masterve bu tek birleştirme taahhüdünü CVS'ye aktarmayı seviyorum . Bir birleştirme commitini dışa aktardığınızda, git'e diff oluşturmak için hangi commit parent'ı kullanacağını söylemeniz gerekir. Ayrıca, birleştirme işleminiz ileri sarma ise bu işe yaramaz ( man git-mergeileri sarma birleştirmenin açıklaması için "BİRLEŞTİRME NASIL ÇALIŞIR" bölümüne bakın ), bu nedenle--no-ffbirleştirmeyi gerçekleştirirken seçenek. İşte bir örnek:
# on master
% git merge --no-ff --log -m "Optional commit message here" topic/branch/name
% git cvsexportcommit -w /path/to/cvs/checkout -u -p -c ORIG_HEAD HEAD
Bu seçeneklerin her birinin ne anlama geldiğini git-cvsexportcommit'in man sayfasında görebilirsiniz . -wSeçeneği git yapılandırmanızda ayarlama seçeneğiniz var:
% git config cvsexportcommit.cvsdir /path/to/cvs/checkout
Yama herhangi bir nedenle başarısız olursa, benim deneyimime göre (maalesef) değiştirilen dosyaları manuel olarak kopyalamak ve cvs istemcisini kullanarak taahhütte bulunmaktan daha iyi olacaksınız. Bununla birlikte, masterkonu dalınızı birleştirmeden önce CVS ile güncel olduğundan emin olursanız, bu olmamalıdır .
Kaydetme herhangi bir nedenle başarısız olursa (ağ / izin sorunları vb.), Hata çıktısının sonunda terminalinize yazdırılan komutu alıp CVS çalışma dizininizde çalıştırabilirsiniz. Genelde şuna benzer:
% cvs commit -F .msg file1 file2 file3 etc
Bir dahaki sefere git cvsimport(en az 10 dakika beklerken), dışa aktarılan kaydetme yamanızın yerel deponuza yeniden aktarıldığını görmelisiniz. CVS kaydı farklı bir zaman damgasına ve muhtemelen farklı bir kaydedici adına sahip olacağından ( cvsimportyukarıdaki baş harfinizde bir yazar dosyası oluşturup oluşturmamanıza bağlı olarak) farklı yürütme kimliklerine sahip olacaktır .
CVS klonunuzu klonlamak
Bunu yapması gereken birden fazla kişi cvsimportvarsa, cvsimport'u gerçekleştiren ve diğer tüm depoları bir klon olarak oluşturulmuş tek bir git deposuna sahip olmak daha verimli olacaktır. Bu mükemmel çalışır ve klonlanmış depo, yukarıda açıklandığı gibi cvsexportcommits gerçekleştirebilir. Ancak bir uyarı var. CVS taahhütlerinin farklı kayıt kimlikleriyle geri gelme şekli nedeniyle (yukarıda açıklandığı gibi), klonlanmış şubenizin merkezi git deposunu izlemesini istemezsiniz. Varsayılan olarak, git clonedeponuzu şu şekilde yapılandırır, ancak bu kolayca giderilebilir:
% git clone [CENTRAL_REPO_HERE]
% cd [NEW_GIT_REPO_DIR_HERE]
% git config --unset branch.master.remote
% git config --unset branch.master.merge
Bu yapılandırmaları kaldırdıktan sonra, merkezi depodan yeni kayıtlar almak istediğinizde nereden ve neyi çekeceğinizi açıkça söylemeniz gerekecektir:
% git pull origin master
Genel olarak, bu iş akışını oldukça yönetilebilir buldum ve tamamen Git'e geçiş yaparken "bir sonraki en iyi şey" pratik değil.