Di Subversion, bagaimana saya harus menyiapkan versi utama baru aplikasi saya?

Saya akan mulai bekerja pada versi baru (versi 4) dari aplikasi komersial saya. Saya menggunakan Subversion.

Berdasarkan pengalaman, kesalahan, dan kesuksesan Anda, bagaimana Anda akan merekomendasikan saya mengatur versi baru di Subversion?

Berikut ini beberapa info: Saya bermaksud untuk terus merilis pembaruan penting dalam versi 3 untuk beberapa waktu setelah versi 4 dirilis. Namun semua pengembangan fitur baru hanya akan ada di versi 4.

Dalam hal ini relevan: Saya adalah pengembang tunggal pada produk ini, dan itu kemungkinan akan tetap demikian.

EDIT: Saya mengetahui tag dan cabang SVN. Saya kira yang saya butuhkan adalah strategi optimal untuk menggunakan tag dan cabang dalam situasi saya.

Yang ingin Anda lakukan adalah membuat Cabang . Itu seperti kedengarannya cabang di pohon sumber Anda, biasanya salinan sumber Anda ketika Anda melepaskannya. Anda akan berkomitmen ke cabang ini untuk pembaruan kritis , dan membangun pembaruan dari cabang ini.

Apa yang Anda komit sekarang adalah trunkdan Anda akan membuat kode versi 4 di sana. Jika ada perubahan besar yang dilakukan ke versi 3, dan Anda ingin memilikinya di versi 4, Anda akan melakukan penggabungan dari cabang (v3) ke trunk (v4) untuk membawa perubahan ke trunk.

Anda juga dapat melihat tag , yang seperti cabang tetapi tautan ke versi tunggal, biasanya revisi versi terakhir (atau yang pertama).

Tergantung.

Anda dapat menyimpan versi 4 di bagasi dan terus mengembangkan di V4. Versi 3 akan menjadi cabang, yang akan Anda perbarui sesuai kebutuhan. Manfaat dari pendekatan ini adalah jika masalah kritis ditemukan di V3 yang juga di V4, Anda bisa melakukan penggabungan sederhana pada file di seluruh cabang.

Opsi lainnya adalah membuat dan repositori yang sama sekali baru untuk V4. Ini akan memberi Anda awal yang baru. Kelemahannya adalah riwayat perubahan diatur ulang dan Anda tidak akan dapat menggabungkan file melalui Subversion. Anda harus menggunakan program seperti Beyond Compare untuk menggabungkan perubahan.

Secara pribadi saya akan tetap dengan pendekatan pertama. Buat cabang V3 dan pertahankan kode dan pembaruan di cabang ini. Kode V4 baru dapat dikembangkan di bagasi.

Saya menemukan panduan yang sangat baik untuk situasi ini :

If you want to be able to both develop a newer version (in trunk) and 
fix bugs on an older version, what you want is a branch for the older 
version. You can fix your bug in the older version's branch, then 
make a new tag of that. 
Example: 
/repo/ 
        project/ 
                trunk/ 
                branches/   
                tags/ 
You've developed your software in trunk and are now ready to call it 
version 1.0. You make a branch and a tag: 
svn cp $REPO/project/trunk $REPO/project/branches/1.x 
svn cp $REPO/project/branches/1.x $REPO/project/tags/1.0 
/repo/ 
        project/ 
                trunk/ 
                branches/ 
                        1.x/    
                tags/ 
                        1.0/ 
Now you continue to develop in trunk, adding new features, and this 
will eventually become version 2.0. But while you're doing this, you 
find a bug in 1.0 and need to fix it quick. So you check out branches/ 
1.x, make the change, test it, and commit it. Then you tag that as 1.1: 
svn cp $REPO/project/branches/1.x $REPO/project/tags/1.1 
/repo/ 
        project/ 
                trunk/ 
                branches/ 
                        1.x/    
                tags/ 
                        1.0/ 
                        1.1/ 
If the bug also exists in trunk, then you need to port your bugfix to 
trunk. "svn merge" can help you there. 
cd trunk-wc 
svn merge -c$R $REPO/project/branches/1.x . 
where $R is the revision in which you fixed the bug on the 1.x 
branch. Now you test the fix in trunk and then commit it. Now the bug 
is fixed in trunk too. 

Apa yang Anda tanyakan adalah strategi cabang (dan gabungkan) untuk digunakan. Jadi, ambil posisi karthik t dan anggap itu sebagai resep.

Untuk latar belakang tertentu, baca sumber daya berikut:

• Buku Merah SVN untuk tata letak repositori (repositori proyek tunggal vs. multi)
• Pola Cabang dalam konteks Anda, Anda akan menggunakan cabang rilis per versi utama
• Pola Manajemen Konfigurasi Perangkat Lunak teori dasar yang digunakan dalam Subversion (dan semua sistem CM lainnya). Lihat di sana polanya , terutama garis rilis di sana.