Üretilen kodu kaynak kontrolünde saklamalı mıyım

Bu benim de yer aldığım bir tartışma. Daha fazla fikir ve bakış açısı almak istiyorum.

DB işlemlerini işlemek için derleme zamanında üretilen bazı sınıflarımız var (Bu özel durumda, SubSonic ile, ancak soru için çok önemli olduğunu düşünmüyorum). Nesil, Visual Studio'da bir ön derleme adımı olarak ayarlanır. Bu nedenle, bir geliştirici (veya resmi oluşturma süreci) bir derlemeyi her çalıştırdığında, bu sınıflar oluşturulur ve ardından projede derlenir.

Şimdi bazı insanlar, bu sınıfların kaynak kontrolünde kaydedilmesinin, aldığınız kodun kendi ortamınızda üretilenlerle eşleşmemesi durumunda kafa karışıklığına neden olabileceğini iddia ediyor.

Genellikle bir kara kutu olarak görülse bile, kodun geçmişini geriye doğru takip etmenin bir yolunu istiyorum.

Herhangi bir argüman veya karşı argüman?

Yukarıda belirtilen nedenlerden dolayı bu noktada kabul edilen bir cevabı seçmeyeceğim.

Kaynak kontrolünde kaydetmek, değerinden daha zahmetlidir.

Herhangi bir değere sahip olması için her inşa ettiğinizde bir commit yapmanız gerekir.

Genellikle oluşturulan kodu (idl, jaxb şeyler, vb.) Çalıştığım yerde kaynak kontrolünün dışında bırakırız ve bu hiç sorun olmadı

Kaynak kodu kontrolüne koyun. Gelecekteki geliştiriciler için yazdığınız her şeyin geçmişine sahip olmanın avantajı, bir senkronizasyondan sonra ara sıra yeniden inşa etmenin küçük acısına ağır basmaktadır.

Kendi kişisel depomda bir kaynak ağacındaki değişiklikleri her göstermek istediğimde, tüm 'oluşturulan dosyalar' değişmiş olarak görünecek ve tamamlanması gerekiyor.

Yalnızca gerçekleştirilen gerçek güncellemeleri içeren ve otomatik olarak oluşturulan değişiklikleri içermeyen daha temiz bir değişiklik listesine sahip olmayı tercih ederim.

Bunları dışarıda bırakın ve ardından bir derlemeden sonra, oluşturulan dosyaların her birine bir 'yoksay' ekleyin.

Buna şu şekilde bakın: nesne dosyalarınızı kaynak kontrolüne kontrol ediyor musunuz? Oluşturulan kaynak dosyalar, tıpkı nesne dosyaları, kitaplıklar ve çalıştırılabilir dosyalar gibi derleme yapılarıdır. Aynı şekilde muamele görmeleri gerekir. Çoğu, oluşturulan nesne dosyalarını ve yürütülebilir dosyaları kaynak denetimine kontrol etmemeniz gerektiğini savunur. Aynı argümanlar üretilen kaynak için de geçerlidir.

Oluşturulan bir dosyanın geçmiş sürümüne bakmanız gerekiyorsa, kaynaklarının geçmiş sürümüyle senkronize edebilir ve yeniden oluşturabilirsiniz.

Oluşturulan herhangi bir türden dosyayı kaynak kontrolüne kontrol etmek, veritabanı denormalizasyonuna benzer. Orada zaman zaman (tipik performans için) bunu yapmak nedenler, ancak veri denormalized sonra doğruluğunu ve tutarlılığı korumak için çok zor hale geldikçe bu büyük bir dikkatle sadece yapılmalıdır.

Üretilen herhangi bir kodu (veya diğer yapıları) kaynak kontrolüne eklemekten kaçınmanız gerektiğini söyleyebilirim. Üretilen kod verilen giriş için aynıysa, yalnızca farklılaştırmak istediğiniz sürümleri kontrol edebilir ve karşılaştırma için kodu oluşturabilirsiniz.

KURU prensibi diyorum. Derleme sırasında bu kod dosyalarını oluşturmak için kullanılan depoda zaten "kaynak dosyalara" sahipseniz, aynı kodun "iki kez" kaydedilmesine gerek yoktur.

Ayrıca, örneğin kod oluşturma bir gün kesintiye uğrarsa, bazı sorunları bu şekilde önleyebilirsiniz.

Hayır, üç nedenden dolayı.

1. Kaynak kodu, uygulamanızın bir anlık görüntüsünü, zaman içindeki bir önceki veya şu andaki bir anlık görüntüsünü yeniden oluşturmak için gerekli ve yeterlidir - ne daha fazlası ne daha azı. Bunun ima ettiği şeyin bir kısmı, kontrol edilen her şeyden birinin sorumlu olduğudur. Genelde yazdığım koddan sorumlu olduğum için mutluyum, ancak yazdığım şeyin bir sonucu olarak üretilen koddan değil.

2. Birinin, güncel olabilecek veya olmayabilecek (ve daha da önemlisi sorumluluk kabul etmek istemediğim) ara kodu kullanarak birincil kaynaklardan bir derlemeyi kısaltmaya çalışmasının cazip gelmesini istemiyorum. Kısmi yapılara dayalı olarak ara koddaki çakışmalarda hata ayıklama konusunda bazı kişilerin anlamsız bir sürece yakalanması için caziptir.

3. Kaynak kontrolüne geçtikten sonra, bir. orada olmak, b. güncel olması ve c. oradaki her şeyle güvenilir bir şekilde entegre edilebilir. Bu, artık kullanmadığım zaman kaldırmayı içerir. Bu sorumluluk ne kadar azsa o kadar iyidir.

Gerçekten kontrol etmen gerektiğini düşünmüyorum.

Elbette üretilen koddaki herhangi bir değişiklik ya gürültü olacaktır - ortamlar arasında değişiklikler ya da başka bir şeyin sonucu olarak değişiklikler - örneğin, DB'nizdeki bir değişiklik. DB'nizin oluşturma komut dosyaları (veya diğer bağımlılıklar) kaynak kontrolündeyse, neden oluşturulan komut dosyalarına da ihtiyacınız var?

Genel kural hayırdır , ancak kodu oluşturmak zaman alıyorsa (DB erişimi, web hizmetleri vb. Nedeniyle) kaynak kontrolünde önbelleğe alınmış bir sürümü kaydetmek ve herkesi acıdan kurtarmak isteyebilirsiniz.

Aletlerinizin de bunun farkında olması ve gerektiğinde kaynak kontrolünden teslim alma işlemini gerçekleştirmesi gerekir, çok fazla araç herhangi bir sebep olmaksızın kaynak kontrolünden çıkış yapmaya karar verir.
İyi bir araç, önbelleğe alınmış sürümü ona dokunmadan (veya dosyadaki zaman adımlarını değiştirmeden) kullanır.

Ayrıca, insanların dosyayı değiştirmemesi için üretilen kodun içine büyük bir uyarı koymanız gerekiyor, üstte bir uyarı yeterli değil, her düzine satırda bir tekrarlamanız gerekiyor.

Üretilen DB kodunu da saklamıyoruz: üretildiği için, herhangi bir sürümde kaynak dosyalardan istediğiniz zaman alabilirsiniz. Bunu saklamak, bayt kodu veya benzerlerini depolamak gibi olur.

Şimdi, belirli bir sürümde kullanılan kod oluşturucunun mevcut olduğundan emin olmanız gerekir! Daha yeni sürümler farklı kodlar oluşturabilir ...

Dışarıda bırakın.

Oluşturulan dosyaları iade ediyorsanız, yanlış bir şey yapıyorsunuz demektir. Yanlış olan farklı olabilir, inşa sürecinizin verimsiz olması veya başka bir şey olabilir, ancak bunun hiç iyi bir fikir olduğunu göremiyorum . Geçmiş, oluşturulanlarla değil, kaynak dosyalarla ilişkilendirilmelidir.

Sadece daha sonra farklılıkları çözmeye, artık yapı tarafından oluşturulmayan dosyaları bulmaya ve ardından bunları silmeye çalışan insanlar için bir baş ağrısı yaratır.

Oluşturulan dosyaları kontrol edenleri bir acı dünyası bekliyor!

Oluşturulan dosyalarınızı iade etmek istediğiniz özel bir durum vardır: diğer dosyaları oluşturmak için kullanılan araçların mevcut olmadığı sistemler üzerine inşa etmeniz gerektiğinde. Bunun klasik örneği ve benim birlikte çalıştığım, Lex ve Yacc kodu. Çok çeşitli platformlar ve mimariler üzerinde inşa etmek ve çalıştırmak zorunda olan bir çalışma zamanı sistemi geliştirdiğimizden, arayüz tanımımız için lexing / ayrıştırma kodunu oluşturmak için gerekli araçlara değil, yalnızca C ve C ++ derleyicilerine sahip olmak için hedef sistemlere güvenebiliriz. çevirmen. Bu nedenle, gramerlerimizi değiştirdiğimizde, onu ayrıştırmak için üretilen kodu kontrol ederiz.

biraz geç gelmek ... neyse ...

Derleyicinin ara dosyasını kaynak sürüm kontrolüne koyar mısınız? Kod üretimi durumunda, tanım gereği kaynak kodu, jeneratörün girdisidir, üretilen kod ise "gerçek" kaynak ile yerleşik uygulama arasındaki ara dosyalar olarak düşünülebilir.

Bu yüzden şunu söyleyebilirim: üretilen kodu sürüm kontrolü altına değil, jeneratör ve girdisini koy.

Somut olarak, yazdığım bir kod üreteci ile çalışıyorum: Üretilen kaynak kodunu sürüm kontrolü altında tutmak zorunda kalmadım. Hatta jeneratör belirli bir olgunluk seviyesine ulaştığı için, girdi (örneğin model açıklaması) değişmesine rağmen üretilen kodun içeriğini gözlemlememe gerek olmadığını bile söyleyebilirim.

Bazı projelerde üretilen kodu kaynak kontrolüne eklerim, ancak bu gerçekten bağlıdır. Temel kuralım, eğer üretilen kod derleyicinin içsel bir parçasıysa, onu eklemeyeceğim. Üretilen kod, bu durumda SubSonic gibi harici bir araçtan geliyorsa, o zaman kaynak kontrolüne eğer eklerim. Bileşeni periyodik olarak yükseltirseniz, hata veya sorun ortaya çıkması durumunda üretilen kaynaktaki değişiklikleri bilmek istiyorum.

Oluşturulan kodun iade edilmesi gerektiği kadarıyla, en kötü durum senaryosu dosyaları manuel olarak farklılaştırmak ve gerekirse dosyaları geri döndürmektir. Svn kullanıyorsanız, dosya gerçekten değişmediyse bir kesinlemeyi reddetmek için svn'ye bir ön işleme kancası ekleyebilirsiniz.

Konfigürasyon yönetiminin görevi (sürüm kontrolü sadece bir parçadır) aşağıdakileri yapabilmektir:

• Teslim edilen her derlemede hangi değişikliklerin ve hata düzeltmelerinin yapıldığını öğrenin.
• Orijinal kaynak kodundan başlayarak, teslim edilen herhangi bir yapıyı tam olarak yeniden üretebilirsiniz. Otomatik olarak oluşturulan kod, dilden bağımsız olarak "kaynak kodu" olarak sayılmaz.

İlki, müşteriye veya son kullanıcıya "geçen hafta bildirdiğiniz hatanın düzeltilmesini ve yeni özelliğin eklendiğini" "iki saat sonra geri gelip" hayır, olmadı "demesini sağlar. Ayrıca "Neden X yapıyor? X'i hiç istemedik" demediklerinden de emin olurlar.

İkincisi, müşteri veya son kullanıcı bir yıl önce yayınladığınız bir sürümde bir hata bildirdiğinde, o sürüme geri dönebileceğiniz, hatayı yeniden oluşturabileceğiniz, düzeltebileceğiniz ve sizin düzeltmenizin hatayı ortadan kaldırdığını kanıtlayabileceğiniz anlamına gelir. derleyicide bazı karışıklıklar ve diğer düzeltmeler.

Bu, derleyicinizin, kitaplıklarınızın vb. De CM'nin bir parçası olması gerektiği anlamına gelir.

Şimdi sorunuzu cevaplamak için: Yukarıdakilerin hepsini yapabilirseniz, o zaman herhangi bir ara temsili kaydetmeniz gerekmez, çünkü yine de aynı cevabı alacağınız garantidir. Yukarıdakilerin hepsini yapamazsanız, tüm bahisler kapalıdır çünkü aynı şeyi iki kez yapıp aynı cevabı alacağınızı asla garanti edemezsiniz. Bu nedenle, tüm .o dosyalarınızı da sürüm kontrolü altına alabilirsiniz.

Gerçekten bağlıdır. Nihayetinde amaç, ihtiyaç duyduğunuzda sahip olduğunuz şeyi yeniden üretebilmektir. İkili dosyalarınızı tam olarak yeniden oluşturabiliyorsanız, onları depolamanıza gerek yoktur. ancak, öğelerinizi yeniden oluşturmak için muhtemelen ilk başta yaptığınız tam konfigürasyonunuza ihtiyacınız olacağını ve bunun yalnızca kaynak kodunuz anlamına gelmediğini, aynı zamanda inşa ortamınız, IDE'niz ve hatta belki başka kitaplıklar anlamına da geldiğini hatırlamanız gerekir. , kullandığınız konfigürasyonda (versiyonlarda) üreteçler veya malzemeler.

Yapı ortamımızı daha yeni sürümlere veya hatta başka bir satıcıya yükselttiğimizde, daha önce sahip olduğumuz ikili dosyaları tam olarak yeniden oluşturamadığımız projelerde sorunla karşılaştım. Bu, dağıtılacak ikili dosyalar, özellikle güvenli ortamda bir tür karmaşaya bağlı olduğunda ve yeniden oluşturulan dosyalar, derleyici yükseltmeleri veya her neyse, nedeniyle bir şekilde farklı olduğunda gerçek bir acıdır.

Yani, üretilen kodu depolar mısınız: Hayır derdim. Onları saklayacağım araçlar da dahil olmak üzere yayımlanan ikili dosyalar veya çıktılar. Ve sonra, onları kaynak kontrolünde saklamaya gerek yoktur, sadece bu dosyaların iyi bir yedeğini alın.

Doğru cevap "Değişir" dir. Müşterinin ihtiyaçlarının ne olduğuna bağlıdır. Kodu belirli bir sürüme geri alabilir ve onsuz herhangi bir harici denetime karşı koyabilirseniz, o zaman hala sağlam bir zeminde değilsinizdir. Geliştiriciler olarak, sadece 'gürültü', ağrı ve disk alanını değil, aynı zamanda fikri mülkiyet yaratma rolüyle görevlendirilmiş olduğumuz gerçeğini ve yasal sonuçları olabilir. Bir web sitesini tam olarak bir müşterinin iki yıl önce gördüğü gibi yeniden oluşturabileceğinizi bir yargıca kanıtlayabilir misiniz?

Genel dosyaları kaydetmenizi veya kaydetmemenizi önermiyorum, hangi şekilde olursanız olun, Karara Konu Uzmanlarını dahil etmediğinize karar verin, muhtemelen yanılıyorsunuz.

Benim görüşüm.

Burada sunulan hem lehinde hem de aleyhinde iyi argümanlar var. Kayıt için, T4 oluşturma sistemini Visual Studio'da oluşturuyorum ve varsayılan kullanıma hazır seçeneğimiz üretilen kodun iade edilmesine neden oluyor. Giriş yapmamayı tercih ediyorsanız biraz daha sıkı çalışmanız gerekiyor.

Benim için temel husus, girdi veya jeneratör güncellendiğinde üretilen çıktının farklılaştırılmasıdır.

Çıktınızı kontrol ettirmediyseniz, yeni sürümün çıktısıyla karşılaştırabilmek için bir üreteci yükseltmeden veya girişi değiştirmeden önce üretilen tüm kodun bir kopyasını almanız gerekir. Bunun oldukça sıkıcı bir süreç olduğunu düşünüyorum, ancak çıktı kontrol edildiğinde, yeni çıktıyı depoya göre ayırmak basit bir mesele.

Bu noktada, "Üretilen koddaki değişiklikleri neden önemsiyorsunuz?" Diye sormak mantıklıdır. (Özellikle nesne koduyla kıyaslandığında.) İçsel bir sorundan ziyade sanatın mevcut durumuna inen birkaç temel neden olduğuna inanıyorum.

1. Oluşturulan kodla sıkı sıkıya örtüşen el yazısı kodu oluşturursunuz. Bugünlerde obj dosyalarında durum böyle değil. Üretilen kod değiştiğinde, ne yazık ki bazı el yazısıyla yazılmış kodların eşleşmesi için değiştirilmesi gerektiği durumdur. İnsanlar genellikle üretilen koddaki genişletilebilirlik noktalarıyla yüksek derecede geriye dönük uyumluluk gözlemlemezler.

2. Oluşturulan kod basitçe davranışını değiştirir. Bunu bir derleyiciden hoş görmezsiniz, ancak adaletli olmak gerekirse, uygulama düzeyinde bir kod oluşturucu, daha geniş bir yelpazede kabul edilebilir çözümlerle farklı bir sorun alanını hedefliyor. Önceki davranışınızla ilgili yaptığınız varsayımların artık bozulup bozulmadığını görmek önemlidir.

3. Jeneratörünüzün çıkışından piyasaya sürülmesine% 100 güvenmiyorsunuz. Derleyici satıcınızın titizliği ile oluşturulmamış ve bakımı yapılmamış olsalar bile, jeneratör araçlarından elde edilecek çok fazla değer vardır. Sürüm 1.0, uygulamanız için mükemmel bir şekilde kararlı olabilirdi ancak belki de 1.1'in şu anda kullanım durumunuz için birkaç kusuru olabilir. Alternatif olarak, giriş değerlerini değiştirirsiniz ve daha önce kullanmadığınız yeni bir jeneratör parçasını kullandığınızı görürsünüz - potansiyel olarak sonuçlar sizi şaşırtabilir.

Esasen tüm bunlar araç olgunluğuna iner - çoğu iş uygulaması kodu oluşturucu, derleyicilerin ve hatta lex / yacc düzeyindeki araçların yıllardır olduğu seviyeye yakın değildir.

Her iki tarafın da geçerli ve makul argümanları var ve ortak bir konuda anlaşmak zor. Sürüm Kontrol Sistemleri (VCS), geliştiricilerin içine koyduğu dosyaları izler ve VCS içindeki dosyaların geliştiriciler tarafından elle yapıldığını varsayar ve geliştiricilerin, dosyaların herhangi bir revizyonu arasındaki tarih ve değişikliklerle ilgilenir. Bu varsayım, iki kavramı eşitler: "Teslim aldığımda bu dosyayı almak istiyorum." ve "Bu dosyanın değişikliğiyle ilgileniyorum."

Şimdi, her iki tarafın argümanları şu şekilde yeniden ifade edilebilir:

• "Kontrol ettiğimde oluşturulan tüm bu dosyaları almak istiyorum çünkü onları bu makinede oluşturacak araca sahip değilim."
• "Bu dosyanın değişikliğiyle ilgilenmediğim için onları VCS'ye koymamalıyım."

Neyse ki, iki gereksinim temelde çelişmiyor gibi görünüyor. Mevcut VCS'lerin bazı uzantıları ile her ikisine de sahip olmak mümkün olmalıdır. Başka bir deyişle, bu yanlış bir ikilemdir. Bir süre düşünürsek, sorunun VCS'lerin tuttuğu varsayımdan kaynaklandığını anlamak zor değil. VCS'ler, geliştiriciler tarafından el yapımı olan dosyaları, geliştiriciler tarafından el yapımı olmayan, ancak bu VCS'nin içinde bulunan dosyalardan ayırmalıdır. Genellikle kaynak dosyaları (kod) olarak adlandırdığımız ilk dosya kategorisi için, VCS'ler şimdi harika bir iş çıkardı. İkinci kategori için, bildiğim kadarıyla, VCS'ler henüz böyle bir konsepte sahip değiller.

Özet

Ne demek istediğimi açıklamak için git'i örnek olarak alacağım.

• git status varsayılan olarak oluşturulan dosyaları göstermemelidir.
• git commit oluşturulan dosyaları anlık görüntü olarak içermelidir.
• git diff varsayılan olarak oluşturulan dosyaları göstermemelidir.

PS

Git kancaları bir geçici çözüm olarak kullanılabilir, ancak git'in yerel olarak desteklemesi harika olur. gitignoregöz ardı edilen dosyalar VCS'lere gitmeyeceğinden, gereksinimlerimizi karşılamıyor.enter code here

Ben tartışırdım. Kodu kontrol eden, yapı numarasını değiştiren, yazılımı oluşturan ve ardından test eden sürekli bir entegrasyon süreci kullanıyorsanız, bu koda yalnızca deponuzun bir parçası olarak sahip olmak daha basit ve daha kolaydır.

Ayrıca, yazılım deponuzdan aldığınız her "anlık görüntünün" bir parçası ve ayrılmaz parçası. Yazılımın bir parçasıysa, havuzun bir parçası olmalıdır.

Evet, kaynak kontrolü altına almak istediğinizi söyleyebilirim. Konfigürasyon yönetimi açısından bakıldığında, bir yazılım yapısı üretmek için kullanılan HER ŞEYİN yeniden oluşturulabilmesi için kontrol edilmesi gerekir. Üretilen kodun kolayca yeniden oluşturulabileceğini anlıyorum, ancak tarih / zaman damgaları iki yapı arasında farklı olacağından aynı olmadığına dair bir argüman yapılabilir. Hükümet gibi bazı alanlarda, birçok kez ihtiyaç duyuyorlar, yapılan bu.

Genel olarak, üretilen kodun kaynak kontrolünde saklanması gerekmez, çünkü bu kodun revizyon geçmişi, onu oluşturan kodun revizyon geçmişi tarafından izlenebilir!

Bununla birlikte, OP'nin üretilen kodu manuel olarak yazmak yerine uygulamanın veri erişim katmanı olarak kullandığı anlaşılıyor. Bu durumda, derleme sürecini değiştiririm ve kodu, çalışma zamanı kodunun kritik bir bileşeni olduğu için kaynak kontrolüne verirdim. Bu ayrıca, geliştiricilerin farklı dallar için aracın farklı sürümünü kullanması gerektiğinde, kod oluşturma aracına olan bağımlılığı derleme sürecinden kaldırır.

Görünüşe göre kodun her derleme yerine yalnızca bir kez oluşturulması gerekiyor. Bir geliştiricinin, bir nesnenin veritabanına erişme şeklini eklemesi / kaldırması / değiştirmesi gerektiğinde, manuel değişiklikler yapmak gibi kod yeniden üretilmelidir. Bu, oluşturma sürecini hızlandırır, veri erişim katmanında manuel optimizasyonların yapılmasına izin verir ve veri erişim katmanının geçmişi basit bir şekilde saklanır.

(Ne yazık ki) birçok türetilmiş kaynağı kaynak kontrolü altına alıyorum çünkü uygun bir inşa ortamı kurmaktan rahatsız olamayan veya bunu kurma becerisine sahip olmayan insanlarla uzaktan çalışıyorum. türetilmiş kaynaklar tam olarak doğru inşa edilmiştir. (Ve Gnu autotools söz konusu olduğunda, ben de o insanlardan biriyim! Her biri farklı bir autotools sürümüyle çalışan üç farklı sistemle çalışamıyorum - ve yalnızca bu sürüm.)

Bu tür bir zorluk muhtemelen, faturaları ödeyen kişinin tek tip bir inşaat ortamında ısrar edebileceği ücretli projelerden ziyade yarı zamanlı, gönüllü, açık kaynaklı projeler için daha fazla geçerlidir.

Bunu yaptığınızda, temelde türetilmiş dosyaları yalnızca bir sitede veya yalnızca uygun şekilde yapılandırılmış sitelerde oluşturmayı taahhüt ediyorsunuz. Makefile dosyalarınız (veya her neyse) nerede çalıştıklarını görecek şekilde ayarlanmalı ve güvenli bir derleme sitesinde çalıştıklarını bilmedikleri sürece kaynakları yeniden türetmeyi reddetmelidir.

Kaynak kodun bir parçasıysa, onu kimin veya neyin oluşturduğuna bakılmaksızın kaynak kontrolüne konulmalıdır. Kaynak kontrolünüzün sisteminizin mevcut durumunu onu yeniden oluşturmak zorunda kalmadan yansıtmasını istersiniz.

Üretilen koda kesinlikle birçok nedenden dolayı kaynak kontrolünde sahip olun. Birçok insanın daha önce söylediklerini yineliyorum, ancak bunu yapmamın bazı nedenleri

1. Kaynak denetimindeki kod dosyalarıyla, Visual Studio ön oluşturma adımınızı kullanmadan kodu derleyebileceksiniz.
2. İki sürüm arasında tam bir karşılaştırma yaparken, üretilen kodun manuel olarak kontrol etmek zorunda kalmadan bu iki etiket arasında değişip değişmediğini bilmek güzel olurdu.
3. Kod oluşturucunun kendisi değişirse, üretilen koddaki değişikliklerin uygun şekilde değiştiğinden emin olmak istersiniz. Örneğin, jeneratörünüz değişirse, ancak çıktının değişmesi gerekmiyorsa, o zaman kodunuzu işleme koymaya gittiğinizde, daha önce oluşturulan ile şimdi oluşturulan kod arasında hiçbir fark olmayacaktır.

Ben oluşturulan dosyaları bırakacaktı dışarı bir kaynak ağacının ama koymak içinde ayrı bir yapı ağacının.

örneğin iş akışı

1. kaynağı normal olarak iade etme / değiştirme / değiştirme / birleştirme (oluşturulan dosyalar olmadan)
2. Uygun durumlarda, kaynak ağacını temiz bir yapı ağacına kontrol edin
3. Bir derlemeden sonra, denetim / düzenleme amaçları için mevcut olması gereken tüm "önemli" dosyaları ("gerçek" kaynak dosyaları, yürütülebilir dosyalar + oluşturulan kaynak dosya) kontrol edin. Bu size, üretilen tüm uygun kod + yürütülebilir dosyalar + her neyse, sürümler / anlık görüntülerin test edilmesi vb. İle ilgili zaman artışlarının bir geçmişini verir ve günlük geliştirmeden ayrıştırılır.

Subversion / Mercurial / Git / vb'de her iki yerdeki gerçek kaynak dosyaların geçmişini birbirine bağlamanın muhtemelen iyi yolları vardır.

Görünüşe göre her iki tarafta da çok güçlü ve ikna edici görüşler var. En çok oylanan tüm cevapları okumanızı ve ardından sizin özel durumunuz için hangi argümanların geçerli olduğuna karar vermenizi tavsiye ederim.

GÜNCELLEME: Bu soruyu gerçekten tek bir kesin cevabın olduğuna inandığım için sordum. Tüm yanıtlara baktığımda, yüksek bir kesinlikle söyleyebilirim ki, böyle bir cevap yok. Karar birden fazla parametreye göre verilmelidir. Diğer cevapları okumak, bu konuya karar vermeniz gerektiğinde kendinize sormanız gereken soru türleri için çok iyi bir kılavuz sağlayabilir.