Saya adalah pengguna Subversion lain yang berjuang untuk mendidik kembali diri saya sendiri dalam Tao tentang kontrol versi terdistribusi.
Ketika menggunakan Subversion, saya adalah penggemar berat pendekatan proyek-kecil, dan, dengan sebagian besar mantan majikan saya, kami akan menyusun cabang repositori kami; tag & trunk sebagai berikut:
branches-+
+-personal-+
| +-alice-+
| | +-shinyNewFeature
| | +-AUTOMATED-+
| | +-shinyNewFeature
| +-bob-+
| +-AUTOMATED-+
| +-bespokeCustomerProject
+-project-+
+-shinyNewFeature
+-fixStinkyBug
tags-+
+-m20110401_releaseCandidate_0_1
+-m20110505_release_0_1
+-m20110602_milestone
trunk
Di dalam pohon sumber itu sendiri, kami akan menggunakan (seperti) struktur berikut:
(src)-+
+-developmentAutomation-+
| +-testAutomation
| +-deploymentAutomation
| +-docGeneration
| +-staticAnalysis
| +-systemTest
| +-performanceMeasurement
| +-configurationManagement
| +-utilities
+-libraries-+
| +-log-+
| | +-build
| | +-doc
| | +-test
| +-statistics-+
| | +-build
| | +-doc
| | +-test
| +-charting-+
| | +-build
| | +-doc
| | +-test
| +-distributedComputing-+
| | +-build
| | +-doc
| | +-test
| +-widgets-+
| +-build
| +-doc
| +-test
+-productLines-+
| +-flagshipProduct-+
| | +-coolFeature
| | +-anotherCoolFeature
| | +-build
| | +-doc
| | +-test
| +-coolNewProduct
+-project-+
+-bigImportantCustomer-+
| +-bespokeProjectOne
| +-bespokeProjectTwo
+-anotherImportantCustomer-+
+-anotherBespokeProject
Idenya adalah (dan masih) menggunakan struktur repositori untuk membantu struktur komunikasi antara tim teknik; bagian bisnis yang menghadap pelanggan dan berbagai pemangku kepentingan lainnya & pakar domain.
Intinya: Sumber dokumen yang duduk di salah satu direktori "proyek" biasakan (dan dapatkan uang) hanya sekali. Dokumen yang berada di salah satu direktori "productLines" menghasilkan uang sebanyak produk yang dijual. Dokumen yang berada di salah satu direktori "perpustakaan" menghasilkan uang sebanyak produk mana pun yang menggunakannya dijual.
Itu membuat gagasan amortisasi biaya eksplisit, dan membantu membangun dukungan untuk penggunaan kembali dokumen sumber di seluruh bisnis.
Ini juga berarti bahwa ada struktur umum di mana alat otomasi bangunan kami dapat beroperasi. (Skrip build kami menjalankan hierarki sumber mencari folder "build" di mana mereka menemukan file konfigurasi yang menentukan bagaimana setiap komponen akan dibangun; proses serupa terjadi untuk pembuatan dan pengujian dokumentasi).
Secara signifikan, produk tempat saya bekerja biasanya membutuhkan waktu yang lama untuk menjalankan tes pengukuran & karakterisasi kinerja; dari 20 hingga 200 jam; menghasilkan suatu tempat antara beberapa GB hingga beberapa TB hasil uji yang diproses / data antara (yang harus disimpan dan diikat ke konfigurasi sistem tertentu sehingga peningkatan kinerja dari waktu ke waktu dapat diukur). Masalah ini membuat manajemen konfigurasi menjadi pertimbangan penting, dan juga memaksakan beberapa persyaratan untuk sentralisasi, karena biasanya sumber daya komputasi yang diperlukan untuk menjalankan pengukuran kinerja dan tes karakterisasi terbatas; (sekelompok kecil 64-128 core).
Sebagai satu catatan akhir; sistem integrasi berkelanjutan tahu bahwa ia perlu memicu pembangunan; analisis statis; uji asap & uji unit dijalankan setiap kali trunk dimodifikasi, setiap kali "tag" cabang diubah, dan setiap kali cabang "OTOMATIS" dimodifikasi. Dengan cara ini, pengembang individu dapat menggunakan sistem CI dengan cabang pribadi mereka, kemampuan penting, IMHO.
Sekarang, inilah pertanyaan saya: Bagaimana saya bisa meniru semua hal di atas (dan memperbaikinya, jika mungkin), dengan Mercurial.
--edit:
Cara berpikir saya saat ini adalah menggunakan Repositori Subversion pusat, untuk menentukan struktur keseluruhan, tetapi untuk memungkinkan penggunaan hg sebagai klien sehingga pengembang dapat memiliki repo tersedia secara lokal.