CVS'den Git'e geçiş: $ Id $ eşdeğeri?

Basit kaynak kodu kontrol araçları hakkında sorular soran bir sürü soruyu okudum ve Git makul bir seçim gibi göründü. Onu hazırladım ve çalıştırıyorum ve şimdiye kadar iyi çalışıyor. CVS ile ilgili sevdiğim bir özellik, bir sürüm numarasının otomatik olarak artırılmasıdır.

Bunun dağıtılmış bir depoda daha az mantıklı olduğunu anlıyorum, ancak bir geliştirici olarak bunun gibi bir şey istiyorum / buna ihtiyacım var. Nedenini açıklayayım:

Emacs kullanıyorum. Düzenli aralıklarla Lisp kaynak dosyalarının üçüncü taraf paketleri için yeni sürümlerini araştırıyorum. Başlığa göre sürüm 1.3 olan foo.el adlı bir dosyam olduğunu varsayalım; En son sürüme bakarsam ve 1.143 veya 2.6 ya da her neyse, görürsem, epey geride olduğumu biliyorum.

Bunun yerine birkaç 40 karakterlik karma görürsem, hangisinin daha sonra olduğunu bilmeyeceğim veya ne kadar sonra olduğuna dair hiçbir fikrim olmayacak. Sırf ne kadar güncel olmadığım hakkında bir fikir edinmek için ChangeLogs'u manuel olarak kontrol etmem gerekse kesinlikle bundan nefret ederim.

Bir geliştirici olarak, gördüğüm kadarıyla bu nezaketi, çıktılarımı kullanan kişilere genişletmek istiyorum (ve belki de kendimi kandırıyorum, ama bunu bir an için bir kenara bırakalım). Her seferinde lanet olası sayıyı kendim artırmayı veya bir zaman damgasını veya bunun gibi bir şeyi hatırlamak zorunda kalmak istemiyorum. Bu gerçek bir PITA ve bunu deneyimden biliyorum.

Öyleyse hangi alternatiflerim var? Bir $ Id: $ eşdeğeri alamazsam, aradığımı başka nasıl sağlayabilirim?

Beklentim, son kullanıcının Git'in kurulu OLMAMASI ve kursa bile yerel bir depoya sahip olmamasıdır (aslında, bu şekilde sunmamayı bekliyorum).

SHA, bir sürümün (kanonik de olsa) yalnızca bir temsilidir. git describeKomut diğerlerini sunar ve böylece oldukça iyi.

Örneğin, Java memcached istemci kaynağımın git describeana dalında çalıştırdığımda , şunu alıyorum:

2.2-16-gc0cd61a

Bu iki önemli şey söylüyor:

1. Bu ağaçta 2.2'den beri tam olarak 16 işlem yapıldı.
2. Kesin kaynak ağacı başkasının klonu üzerinde görüntülenebilir.

Diyelim ki, versionbu numarayı göstermek için kaynakla bir dosya paketlediniz (hatta dağıtım için tüm içeriği yeniden yazdınız). Diyelim ki paketlenmiş sürüm 2.2-12-g6c4ae7a(bir sürüm değil, geçerli bir sürüm).

Artık tam olarak ne kadar ileri (4 kaydedilmesini) vardır arkasında görebilirsiniz ve tam olarak hangi 4 kaydedilmesini görebilirsiniz:

# The RHS of the .. can be origin/master or empty, or whatever you want.
% git log --pretty=format:"%h %an %s" 2.2-12-g6c4ae7a..2.2-16-gc0cd61a
c0cd61a Dustin Sallings More tries to get a timeout.
8c489ff Dustin Sallings Made the timeout test run on every protocol on every bui
fb326d5 Dustin Sallings Added a test for bug 35.
fba04e9 Valeri Felberg Support passing an expiration date into CAS operations.

Şimdiye kadar Git'te $ Id: $ desteği var. README dosyası için etkinleştirmek için .gitattributes içine "README ident" yazmanız gerekir . Dosya adlarında joker karakterler desteklenir. Ayrıntılar için man git özniteliklerine bakın.

Bu, OP'nin mantıksız bir talebi değil.

Benim kullanım durumum:

1. Git'i kendi kişisel kodum için kullanıyorum, bu nedenle başkalarıyla işbirliği yapmıyorum.
2. /usr/local/binHazır olduklarında girebilecek sistem Bash betiklerini orada tutuyorum .

Üzerinde aynı Git deposuna sahip üç ayrı makine kullanıyorum. /usr/local/binEl ile bir "diff -u <repo version> <version in / usr / local / bin>" yapmadan şu anda içinde bulunduğum dosyanın hangi "sürümünü" bilmek güzel olurdu .

Negatif olanlarınız için, başka kullanım durumlarının da olduğunu unutmayın. Git deposundaki dosyalar "nihai" konumları olduğu için herkes Git'i ortak çalışma için kullanmaz.

Her neyse, bunu yaptığım yol, arşivde şöyle bir öznitelik dosyası oluşturmaktı:

cat .git/info/attributes
# see man gitattributes
*.sh ident
*.pl ident
*.cgi ident

Sonra dosyada bir yere $ Id $ koyun (shebang'dan sonra koymak isterim).

Taahhüt. Bunun beklediğim gibi genişletmeyi otomatik olarak yapmadığını unutmayın. Dosyayı yeniden yazmanız gerekiyor, örneğin,

git commit foo.sh
rm foo.sh
git co foo.sh

Ve sonra genişlemeyi göreceksiniz, örneğin:

$ head foo.sh
#!/bin/sh

# $Id: e184834e6757aac77fd0f71344934b1cd774e6d4 $

Bazı iyi bilgiler şu bölümdedir: Bir Git deposu için kimlik dizesini nasıl etkinleştirebilirim? .

Bunun Git'te olacağından emin değilim. Linus'tan alıntı yapmak için :

"Anahtar kelime ikamesi kavramı tamamen aptalca. Ağaçları katran topları gibi serbest bırakırken buna sahip olmak istiyorsanız, gerçek içerik izlemenin" dışında "yapmak önemsizdir."

Günlüğü kontrol etmek oldukça kolaydır - foo.el'in kararlı dalını izliyorsanız, kararlı dal günlüğünde yerel kopyanızda olmayan hangi yeni işlemlerin olduğunu görebilirsiniz. CVS'nin dahili sürüm numarasını simüle etmek istiyorsanız, son işlemenin zaman damgasını karşılaştırabilirsiniz.

Düzenleme: Bunun için başka birinin komut dosyalarını yazmalı veya kullanmalısınız, elbette bunu manuel olarak yapmayın.

Yazdığım gibi önce :

Bazaar gibi DSCM araçlarıyla mantıklı bir sürüm numarası gösteren otomatik olarak oluşturulmuş Kimlik etiketlerine sahip olmak imkansızdır çünkü herkesin gelişim çizgisi diğerlerinden farklı olabilir. Yani birisi bir dosyanın "1.41" sürümüne başvurabilir, ancak bu dosyanın "1.41" sürümünüz farklıdır.

Temel olarak, $ Id $, Bazaar, Git ve diğer dağıtılmış kaynak kodu yönetim araçlarıyla hiçbir anlam ifade etmiyor.

Ben de aynı sorunu yaşadım. Bir hash dizesinden daha basit ve arşive bağlanmaya gerek kalmadan aracı kullanan kişiler için mevcut olan bir sürüme sahip olmam gerekiyordu.

Bunu bir Git ön işleme kancası ile yaptım ve betiğimi kendini otomatik olarak güncelleyebilecek şekilde değiştirdim.

Versiyonu, yapılan işlemlerin sayısına dayandırıyorum. Bu hafif bir yarış durumu çünkü iki kişi aynı anda taahhütte bulunabilir ve ikisi de aynı sürüm numarasını taahhüt ettiklerini düşünüyor, ancak bu projede çok fazla geliştiricimiz yok.

Örnek olarak, Ruby'de olan bir komut dosyam var ve bu kodu ona ekliyorum - oldukça basit bir koddur, bu nedenle farklı bir dilde bir şey kontrol ediyorsanız farklı dillere geçiş yapmak kolaydır (tabii ki bu metin dosyaları gibi çalıştırılamayan kontroller ile kolayca çalışmaz). Ekledim:

MYVERSION = '1.090'
## Call script to do updateVersion from .git/hooks/pre-commit
def updateVersion
  # We add 1 because the next commit is probably one more - though this is a race
  commits = %x[git log #{$0} | grep '^commit ' | wc -l].to_i + 1
  vers = "1.%0.3d" % commits

  t = File.read($0)
  t.gsub!(/^MYVERSION = '(.*)'$/, "MYVERSION = '#{vers}'")
  bak = $0+'.bak'
  File.open(bak,'w') { |f| f.puts t }
  perm = File.stat($0).mode & 0xfff
  File.rename(bak,$0)
  File.chmod(perm,$0)
  exit
end

Ve sonra betiğe bir komut satırı seçeneği (-updateVersion) ekliyorum, bu yüzden eğer onu "tool -updateVersion" olarak adlandırırsam, araç için sadece "MYVERSION" değerini kendi içinde değiştiren ve ardından çıkan araç için updateVersion'ı çağırır (siz Eğer isterseniz diğer dosyaları da açılmışsa güncellemesini sağlayın).

Kurulum tamamlandıktan sonra Git kafasına gidiyorum ve içinde çalıştırılabilir tek satırlık bir bash betiği oluşturuyorum .git/hooks/pre-commit.

Komut dosyası basitçe Git dizininin başına geçer ve komut dosyamı ile çağırır -updateVersion.

Pre-commit betiğini her kontrol ettiğimde, betiğimi -updateVersion ile çalıştıran çalıştırılıyor ve ardından MYVERSION değişkeni, kaydetme sayısının ne olacağına bağlı olarak güncelleniyor. Sihirli!

$ Anahtar Kelimeler $ sizin için gerekliyse, bunun yerine Mercurial'a bakmayı deneyebilirsiniz ? İstediğinizi uygulayan bir hgkeyword uzantısına sahiptir. Mercurial zaten bir DVCS olarak ilginç.

Git depolarıyla yapılan bir şey de tagnesneyi kullanmaktır . Bu, herhangi bir tür dizeyle bir yürütmeyi etiketlemek için kullanılabilir ve sürümleri işaretlemek için kullanılabilir. git tagTüm etiketleri döndüren komutu ile bir depodaki bu etiketleri görebilirsiniz .

Bir etiketi kontrol etmek kolaydır. Örneğin, bir etiket v1.1varsa, bu etiketi aşağıdaki gibi bir şubeye kontrol edebilirsiniz:

git checkout -b v1.1

En üst düzey bir nesne olduğu için, bu işlemin tüm geçmişini göreceksiniz, ayrıca farkları çalıştırabilecek, değişiklikler yapabilecek ve birleştirebileceksiniz.

Sadece bu da değil, üzerinde bulunduğu dal ana hatta birleştirilmeden silinmiş olsa bile bir etiket kalır.

Doğru anladıysam, esasen, son güncellemenizden bu yana belirli bir dosyada kaç kaydetme gerçekleştiğini bilmek istersiniz.

Önce uzak başlangıçtaki değişiklikleri alın, ancak bunları şubenizle birleştirmeyin master:

% git fetch

Ardından, masterşubeniz ile uzaktan kumanda arasında belirli bir dosyada gerçekleşen değişikliklerin günlüğünü alın origin/master.

% git log master..origin/master foo.el

Bu size son birleşti beri uzak depoda meydana gelmiş tüm kaydedilmesini ait günlük iletilerini verir origin/masterSİZİN içine master.

Sadece değişikliklerin sayılmasını istiyorsanız, yönlendirin wc. Şöyle söyle:

% git rev-list master..origin/master foo.el | wc -l

İnsanların ne kadar eski oldukları hakkında bir fikir edinmelerini istiyorsanız, Git onları oldukça kolay birkaç yoldan bilgilendirebilir. Örneğin, gövde ve bagajındaki son işlemin tarihlerini karşılaştırırlar. git cherryBagajınızda, kendilerinde bulunmayan kaç işlem yapıldığını görmek için kullanabilirler .

Tüm istediğiniz buysa, bir sürüm numarası olmadan sağlamanın bir yolunu ararım.

Ayrıca, istediklerinden emin olmadığınız sürece nezaketinizi kimseye sunmaya zahmet etmem. :)

Genişletmeyi bilgi havuzundaki tüm alt dizinlerdeki tüm dosyalara uygulamak için, arşivdeki .gitattributesen üst düzey dizine (yani .gitignoredosyayı normalde koyacağınız yere ) aşağıdakileri içeren bir dosya ekleyin :

* ident

Bunu etkili bir şekilde görmek için, önce dosyaları herhangi bir şekilde silmek veya düzenlemek gibi etkili bir şekilde teslim almanız gerekir. Ardından bunları şu şekilde geri yükleyin:

git checkout .

Ve aşağıdaki $Id$gibi bir şeyle değiştirildiğini görmelisiniz :

$Id: ea701b0bb744c90c620f315e2438bc6b764cdb87 $

Kimden man gitattributes:

ident

Bir yol için öznitelik kimliği ayarlandığında Git, blob nesnesindeki $ Id $ 'ı $ Id: ile değiştirir, ardından 40 karakterlik onaltılık blob nesnesi adı ve ardından ödeme sırasında dolar işareti $ gelir. $ Id: ile başlayan ve çalışma ağacı dosyasında $ ile biten herhangi bir bayt dizisi, giriş sırasında $ Id $ ile değiştirilir.

Bu kimlik, dosyanın yeni bir sürümü her işlendiğinde değişecektir.

RCS kimlikleri tek dosyalı projeler için iyidir, ancak diğerleri için $ Id $ proje hakkında hiçbir şey söylemez (sahte bir sürüm dosyasına sahte check-in yapmadığınız sürece).

Yine de, dosya başına veya commit düzeyinde $ Author $, $ Date $, $ Revision $, $ RCSfile $, vb. Eşdeğerlerinin nasıl elde edileceği (bazı anahtar kelimelerin başka olduğu yerlere nasıl koyulur) ilgilenebilir. soru). Bunlar hakkında bir cevabım yok, ancak özellikle dosyalar (şimdi Git'te) RCS uyumlu sistemlerden (CVS) geliyorsa, bunları güncelleme gereksinimini görüyorum.

Kaynaklar herhangi bir Git deposundan ayrı olarak dağıtılırsa bu tür anahtar sözcükler ilginç olabilir (ben de öyle yapıyorum). Benim çözümüm şöyle:

Her projenin kendine ait bir dizini vardır ve proje kökünde .version, mevcut sürümü (kaynakları dışa aktarırken kullanılacak ad) hangi içeriğin açıklandığı adında bir metin dosyasına sahibim .

Bir sonraki sürüm için çalışırken, bir komut dosyası bu .versionsayıyı, bazı Git sürüm tanımlayıcılarını (gibi git describe) ve monoton bir yapı numarasını .build(artı ana bilgisayar ve tarih) son programa bağlı otomatik olarak oluşturulmuş bir kaynak dosyaya çıkarır , böylece bulabilirsiniz. hangi kaynaktan ve ne zaman inşa edildiğinden

Ayrı dallarda yeni özellikler geliştiriyorum ve ilk yaptığım şey dizeye eklemek n("sonraki" için) .version(aynı kökten gelen birden çok dal aynı geçici .versionnumarayı kullanır). Yayınlamadan önce hangi şubelerin birleştirileceğine karar verdim (umarım hepsinin aynı olması gerekir .version). Birleştirmeyi gerçekleştirmeden önce .version, bir sonraki numaraya (birleştirilmiş özelliklere bağlı olarak büyük veya küçük güncelleme) güncellerim.

Git commit bilgilerinin kodunuzda erişilebilir olmasını istiyorsanız, oraya ulaşmak için bir ön oluşturma adımı yapmanız gerekir . C / C ++ için bash'de aşağıdaki gibi görünebilir:

prebuild.sh

#!/bin/bash
commit=$(git rev-parse HEAD)
tag=$(git describe --tags --always ${commit})
cat <<EOF >version.c
#include "version.h"
const char* git_tag="${tag}";
const char* git_commit="${commit}";
EOF

ile version.hbenzeyen:

#pragma once
const char* git_tag;
const char* git_commit;

Ardından, ihtiyaç duyduğunuz her yerde kodunuzda #include "version.h"ve referansınızda git_tagveya git_commitgerektiği gibi.

Ve Makefilebunun gibi bir şeye sahip olabilirsiniz:

all: package
version:
  ./prebuild.sh
package: version
  # the normal build stuff for your project

Bunun şu avantajları vardır:

• dallanma, kiraz toplama vb. birleştirme ne olursa olsun bu yapı için şu anda doğru değerleri almak .

Bu uygulama prepublish.shaşağıdaki sakıncalara sahiptir:

• git_tag/ git_commitdeğişmemiş olsa bile yeniden derlemeye zorlamak .
• kaydedilmemiş, ancak yapıyı etkileyen yerel değiştirilmiş dosyaları dikkate almaz.
  • bu kullanım git describe --tags --always --dirtydurumunu yakalamak için kullanın.
• genel ad alanını kirletiyor.

prebuild.shBu sorunları önleyebilecek bir meraklı , okuyucu için bir alıştırma olarak bırakılmıştır.

Belirteç değişiminin sürüm kontrol araçlarından çok araç oluşturma işlemine ait olduğunu düşünenlere katılıyorum.

Sürüm etiketlendiği sırada kaynaklarınızda sürüm kimliklerini ayarlamak için bazı otomatik yayın aracına sahip olmanız gerekir.

Etiket adları ve diğer ilgili bilgiler artık, export-substözelliği aracılığıyla Git tarafından otomatik olarak doğrudan dosyalara düzenlenebilir gitattributes(5). Bu elbette git archivesürümleri oluşturmak için kullanımının kullanılmasını gerektirir ve yalnızca sonuçta ortaya çıkan tar dosyasında ikame düzenlemeleri görünür olacaktır.

Örneğin .gitattributesdosyaya aşağıdaki satırı koyun:

* export-subst

Ardından kaynak dosyalarda şuna benzer bir satır ekleyebilirsiniz:

#ident  "@(#)PROJECTNAME:FILENAME:$Format:%D:%ci:%cN:%h$"

Ve örneğin aşağıdakiler tarafından oluşturulan bir sürümde şöyle görünecek şekilde genişleyecektir git archive v1.2.0.90:

#ident  "@(#)PROJECTNAME:FILENAME:HEAD -> master, tag: v1.2.0.90:2020-04-03 18:40:44 -0700:Greg A. Woods:e48f949"

Emacs kullandığınız için şanslı olabilirsiniz :)

Bu soruya tesadüfen rastladım ve ayrıca tesadüfen birkaç gün önce Lively ile geldim , belgenizde Emacs Lisp'in canlı parçalarına sahip olmanızı sağlayan bir Emacs paketi. Dürüst olmaya çalışmadım ama bunu okurken aklıma geldi.

Ayrıca SCCS, RCS ve CVS'den ( %W% %G% %U%) geldim .

Ben de benzer bir zorluk yaşadım. Onu çalıştıran herhangi bir sistemde bir kod parçasının hangi sürümünün olduğunu bilmek istedim. Sistem herhangi bir ağa bağlı olabilir veya olmayabilir. Sistemde Git kurulu olabilir veya olmayabilir. Sistemde GitHub deposu kurulu olabilir veya olmayabilir.

Birkaç kod türü için (.sh, .go, .yml, .xml, vb.) Aynı çözümü istedim. Git veya GitHub bilgisi olmayan herhangi birinin "Hangi sürümü çalıştırıyorsunuz?" Sorusuna cevap vermesini istedim.

Bu yüzden, birkaç Git komutunun etrafına sarmalayıcı dediğim şeyi yazdım. Bir dosyayı bir sürüm numarası ve bazı bilgilerle işaretlemek için kullanıyorum. Sorunumu çözüyor. Size yardımcı olabilir.

https://github.com/BradleyA/markit

git clone https://github.com/BradleyA/markit
cd markit

Bu sorunu kendi başıma çözmek için, işleme sonrası kanca olarak küçük "hack" oluşturdum:

echo | tee --append *
git checkout *

Blogumdaki bu yazıda daha ayrıntılı olarak belgelenmiştir .