Trong Subversion, tôi nên thiết lập phiên bản chính mới cho ứng dụng của mình như thế nào?

Tôi sắp bắt đầu làm việc với phiên bản mới (phiên bản 4) của ứng dụng thương mại của mình. Tôi sử dụng Subversion.

Dựa trên kinh nghiệm, sai lầm và thành công của bạn, bạn muốn giới thiệu tôi thiết lập phiên bản mới trong Subversion như thế nào?

Dưới đây là một số thông tin: Tôi dự định tiếp tục phát hành các bản cập nhật quan trọng trong phiên bản 3 một thời gian sau khi phiên bản 4 được phát hành. Tuy nhiên, tất cả sự phát triển của các tính năng mới sẽ chỉ có trong phiên bản 4.

Trong trường hợp có liên quan: Tôi là nhà phát triển solo trên sản phẩm này và điều đó có khả năng vẫn là trường hợp.

EDIT: Tôi biết các thẻ và chi nhánh của SVN. Tôi đoán những gì tôi cần là một chiến lược tối ưu để sử dụng thẻ và chi nhánh trong tình huống của tôi.

Những gì bạn muốn làm là tạo Chi nhánh . Nó giống như âm thanh của một nhánh trong cây nguồn của bạn, thường là bản sao của nguồn khi bạn phát hành nó. Bạn sẽ cam kết với chi nhánh này cho các bản cập nhật quan trọng và xây dựng bản cập nhật từ chi nhánh này.

Những gì bạn đang cam kết ngay bây giờ sẽ là trunkvà bạn sẽ mã phiên bản 4 trong đó. Nếu bất kỳ thay đổi lớn nào được cam kết cho phiên bản 3 và bạn muốn có nó trong phiên bản 4, bạn sẽ thực hiện hợp nhất từ nhánh (v3) sang trung kế (v4) để đưa các thay đổi qua trung kế.

Bạn cũng có thể xem các thẻ giống như các nhánh nhưng liên kết đến một phiên bản duy nhất, điển hình là phiên bản cuối cùng của phiên bản (hoặc phiên bản đầu tiên).

Nó phụ thuộc.

Bạn có thể giữ phiên bản 4 trong thân cây và tiếp tục phát triển trên V4. Phiên bản 3 sẽ là một nhánh, mà bạn sẽ cập nhật khi cần. Lợi ích của phương pháp này là nếu một vấn đề quan trọng được phát hiện trong V3 cũng ở V4, bạn có thể thực hiện hợp nhất đơn giản trên (các) tệp trên các nhánh.

Tùy chọn khác là tạo và kho hoàn toàn mới cho V4. Điều này sẽ cung cấp cho bạn một khởi đầu mới. Nhược điểm là lịch sử thay đổi được đặt lại và bạn sẽ không thể hợp nhất các tệp thông qua Subversion. Bạn sẽ phải sử dụng một chương trình như Beyond So sánh để hợp nhất trong các thay đổi.

Cá nhân tôi sẽ gắn bó với cách tiếp cận đầu tiên. Tạo một nhánh V3 và duy trì mã và các bản cập nhật trong nhánh này. Mã V4 mới có thể được phát triển trong thân cây.

Tôi tìm thấy một hướng dẫn tuyệt vời cho tình huống này :

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. 

Những gì bạn đang hỏi là chiến lược chi nhánh (và hợp nhất) để sử dụng. Vì vậy, lấy bài của karthik t và lấy đó làm công thức.

Đối với một số nền tảng, đọc các tài nguyên sau:

• Sách đỏ SVN cho bố cục kho lưu trữ (kho đơn so với nhiều dự án)
• Các mẫu chi nhánh trong ngữ cảnh của bạn, bạn sẽ sử dụng một nhánh phát hành cho mỗi phiên bản chính
• Quản lý cấu hình phần mềm Mô hình lý thuyết cơ sở được sử dụng trong Subversion (và tất cả các hệ thống CM khác). Xem ở đó các mẫu , đặc biệt là dòng phát hành ở đó.