İlk olarak, bu konuda biliyorum: http://stackoverflow.com/questions/51217/how-would-you-organize-a-subversion-repository-for-in-house-software-projects Gelecek, gerçek soru: Benim takım bizim depoyu yeniden yapılanma ve organize etmek için nasıl ipuçları arıyorum. (Bu durumda SVN). Ne ile geldi işte. Bir depo, birden fazla proje ve birden fazla svn:dışındakiler çapraz referanslar

\commonTools /*tools used in all projects. Referenced in each project with svn:externals*/
   \NUnit.v2.4.8
   \NCover.v.1.5.8
   \<other similar tools>
\commonFiles /*settings strong name keys etc.*/
   \ReSharper.settings
   \VisualStudio.settings
\thrash /*each member of the team has thrash for samples, experiments etc*/
   \user1
   \user2
\projects
   \Solution1 /*Single actual project (Visual Studio Solution)*/
      \trunk
         \src
             \Project1 /*Each sub-project resulting in single .dll or .exe*/
             \Project2
         \lib
         \tools
         \tests
         \Solution1.sln
      \tags
      \branches
   \Solution2
      \trunk
         \src
             \Project3 /*Each sub-project resulting in single .dll or .exe*/
             \Project1 /*Project1 from Solution1 references with svn:externals*/
         \lib
         \tools
         \tests
         \Solution2.sln
      \tags
      \branches

Sözlüğü temizlemek için: Çözüm, tek ürün, Proje, Visual Studio bir Proje (bir tek neden .dll veya tek .exe)

Bu depoyu düzenlemek için plan nasıl. Asıl sorun, birden çok Çözüm var, ama Çözümler arasında Projeleri paylaşmak istiyoruz. Hiçbir nokta gerçekten kendi Çözümlerini bu ortak Projeler hareket olduğunu düşündüm, ve yerine svn:Çözümler arasında Projeler paylaşmak dışındakiler kullanmaya karar verdik. Biz de depo olarak tek bir yerde araçları ve 3. parti kütüphaneleri ortak set tutmak istiyorum, ve onları svn ile her Çözüm:dışındakiler onları referans.

Bu düzen hakkında ne düşünüyorsunuz? Özellikle svn kullanımı hakkında:dışındakiler. İdeal bir çözüm değil, ama tüm artılarını ve eksilerini göz önünde bulundurarak, aklımıza gelen en iyisi bu. Bunu nasıl yapardın?

Eğer benim öneriler (yıl) takip eğer mümkün olacak:

-- her yerde her proje, kaynak denetimi, proje kök dizini alt yapısını korumak geçirin

her yerde, her proje en az risk ve en az hazırlık ile herhangi bir makine inşa

-- her proje tamamen tek başına, ikili bağımlılıkları (yerel "" ve "çıkış" dizinler) . kütüphanesine erişimi olduğu sürece inşa

-- bağımsız oldukları ve projeleri herhangi bir kombinasyonu ile inşa çalışması

-- bağımsız oldukları oluşturmak ve birden fazla kopyasını tek bir proje sürümleri,

-- oluşturulan dosyaları veya kitaplıkları ile kaynak denetimi depo yığılan kaçının

Tavsiye ederim (şikayet):

1. Her projenin tek bir ana ' m, yüzme gibi üretmek için kullanılır .DLL, .EXE ya da .JAR (Visual Studio ile varsayılan).

2. Tek bir kök ile bir dizin ağacı olarak her proje yapısı.

3. Oluşturun otomatik bir komut dosyası oluşturmak için her proje kendi kök dizin olacak inşa sıfırdan, HİÇBİR bağımlılıkları üzerinde bir IDE (ama yok engel olmak için inşa edilen IDE, eğer uygulanabilir).

4. NAnt için düşünün .Windows, ya da benzer bir şey üzerinde NET projeler OS, hedef platform, vb dayalı.

5. Her proje inşa script başvuru harici (3. şahıs) bağımlılıkları tek bir yerel paylaşılan "kütüphane" dizin, her tür ikili TAM olarak tespit sürüm: %DirLibraryRoot%\ComponentA-1.2.3.4.dll, %DirLibraryRoot%\ComponentB-5.6.7.8.dll.

6. Her proje tek bir komut dosyası yerel olarak paylaşılan "çıkış" dizini: %DirOutputRoot%\ProjectA-9.10.11.12.dll, %DirOutputRoot%\ProjectB-13.14.15.16.exe. birincil teslim Yayımla inşa olun

7. Her proje senaryosu başvuru yapılandırılabilir üzerinden bağımlılıkları kurmak ve tam sürüm bilgisi mutlak yollar (yukarıda) "ve" çıkış "dizinleri VE HİÇBİR YERDE. kütüphanede olun

8. HİÇ başvuru doğrudan bir proje edeyim, başka bir proje veya içeriğini herhangi bir "dizin (yukarıda). çıkış birincil çıktıları için başvurular sağlar--sadece

9. Her proje başvurusu komut dosyası oluşturmak için gerekli yapı araçları tarafından yapılandırılabilir ve tam sürüm bilgisi mutlak bir yol yapmak: %DirToolRoot%\ToolA\1.2.3.4, %DirToolRoot%\ToolB\5.6.7.8.

10. Her proje mutlak bir yol projesine göre script başvuru kaynağı içerik oluşturmak kök dizin: ${project.base.dir}/src, ${project.base.dir}/tst aracı inşa göre değişir sözdizimi ().

11. Bir proje başvurusu için komut dosyası oluşturmak gerektirir mutlak, yapılandırılabilir bir yol üzerinden HER bir dosya ya da dizin (dizin yapılandırılabilir bir değişken tarafından belirtilen en köklü): ${project.base.dir}/some/dirs ${env.Variable}/other/dir.

12. ASLA .\some\dirs\here ..\some\more\dirs, her ZAMAN mutlak yolları kullanmak gibi bir proje başvurusu bir ŞEY için komut dosyası oluşturmak göreli bir yol ile sağlar.

13. HİÇ bir proje başvurusu için betik bir ŞEY yapılandırılabilir kök dizini yok, mutlak bir yol kullanarak, C:\some\dirs\here \\server\share\more\stuff\there gibi izin verir.

14. Her yapılandırılabilir kök dizin bir proje tarafından başvurulan komut dosyası oluşturmak için, bu başvuruları için kullanılacak bir ortam değişkeni tanımlayın.

15. Her makine yapılandırma oluşturmalısınız ortam değişkenleri sayısını en aza indirmek için bir girişim.

16. Her makine, makine (ve muhtemelen bu kullanıcı için özel eğer ilgili ise) için özel olan gerekli ortam değişkenleri tanımlayan bir kabuk oluşturun.

17. Kaynak denetimi içine özel makine konfigürasyonu kabuk koymayın; bunun yerine, her proje için, proje senaryonun bir kopyasını şablon olarak kök dizini kaydetme.

18. Eğer tanımlanan her proje script çevre değişkenlerini her kontrol için inşa GEREKTİRİR ve anlamlı bir mesaj ile iptal.

19. Eğer bu dosya mevcut değilse, her bir proje senaryosu bağımlı inşa aracı kendi yürütülebilir dosyaları her biri, dış kütüphane dosyaları ve bağımlı proje teslim dosyaları kontrol etmek için inşa GEREKTİRİR ve anlamlı bir mesaj ile iptal.

20. Günaha kaynak kontrolü-hiçbir proje çıktıları, üretilen kaynak, oluşturulan dokümanlar, vb HERHANGİ oluşturulan dosyaları işlemek için DİRENİYORLAR.

21. Eğer bir IDE kullanıyorsanız, kontrol edebilirsiniz dosya ve kaynak denetimi (Visual Studio proje dosyalarını içerir) onlara güvenme ne olursa olsun üretmek.

22. Tüm harici kütüphaneler ve araçlar resmi bir kopyasını içeren bir sunucu kurmak, yüklü/geliştirici iş istasyonları üzerinde kopyalanması ve yapı makineleri. Bu, kaynak denetimi depo ile birlikte yedekleyin.

23. HAYIR geliştirme araçları ne şekilde olursa olsun, sürekli entegrasyon sunucusu (makine yapı) kurmak.

24. Harici kütüphaneler ve teslimleri, Sarmaşık gibi yönetmek için bir araç (Karınca ile kullanılır) düşünün.

25. Başlangıçta seni çok mutlu edecek Maven kullanmayın, ve seni ağlatmak sonunda.

Bunların hiçbiri Subversion için özel olduğunu unutmayın, ve çoğu projeler herhangi bir işletim sistemi, donanım, platform, dil, vb için hedeflenen genel. OS - ve araca özgü sözdizimi, ama gösterim için tek seçenek OS veya aracı için tercüme eder umarım biraz kullandım.

Ek not ile ilgili olarak Visual Studio çözümleri: kaynak denetimi içine koyma! Bu yaklaşım, hiç gerek yok ya onlara (sadece Visual Studio proje dosyaları gibi) oluşturabilirsiniz. Ancak, en iyisi bırakmak için bulduğum çözüm bireysel geliştiriciler için uygun gördükleri şekilde oluşturma/kullan (ama kaynak için kontrol kontrol) dosyaları. Hangi ben benim geçerli proje başvurusu benim iş istasyonu üzerinde Rob.sln bir dosya(lar) duruyorum. Benim tüm projeleri tek başına bu yana, add/olacak projeler no proje tabanlı bağımlılık başvurular) ortadan kaldırabilirim.

Lütfen Subversion dışındakiler (veya başka araçlar içinde benzer) kullanmayın, anti-kalıp ve, bu nedenle, bunlar gereksizdir.

Sadece serbest bırakma işlemi otomatik hale getirmek istiyorum sürekli entegrasyon, hatta uygulamak için bir komut dosyası oluşturun. Bir tek kabuk betiği: sürer parametreleri proje adı (olarak listelenen deposu) ve etiket adı oluşturur bir geçici dizin içinde yapılandırılabilir bir kök dizini, kontrol kaynağı için verilen proje adı ve tag name (tarafından inşa uygun URL durumda Subversion) için bir geçici dizin, gerçekleştirir temiz bir yapı çalışan testleri ve paketleri teslim. Bu kabuk betiği herhangi bir proje üzerinde çalışmak ve bir parçası "araçlar" projesi. yapı olarak kaynak denetimine iade edilmelidir Sürekli entegrasyon sunucusu inşaat projeleri için temel olarak bu komut dosyasını kullanabilirsiniz, ya da (ama yine de kendi isteyebilir) olabilir.

@VonC: çok çalışmak her zaman "ant.jar" yerine "ant-a.b.c.d.jar" sonra seni yakar ne zaman inşa script sonları çünkü bilmeden ran ile uyumsuz bir sürümü Karınca. Bu Ant 1.6.5 ve 1.7.0 arasında özellikle yaygındır. Genelleme her ZAMAN kullanıldığını bilmek istiyorum, platformu (A. B, C, D, Java) ve oluşturma aracı (Karınca E. F. G. H) de dahil olmak üzere. Aksi halde, sonunda bir hata ile karşılaşacak ve ilk BÜYÜK sorun, çeşitli bileşenlerin sürümleri dahil aşağı izleme. Sadece daha iyi bu sorunu ön çözmek için.