Đưa ra chiến lược kiểm soát phiên bản cho SVN


9

Tôi sẽ thử và đưa ra chiến lược kiểm soát phiên bản cho công ty của mình; chúng tôi hiện đang sử dụng SVN nhưng không có cấu trúc nào cho nó - về cơ bản chúng tôi chỉ có một thân cây và chỉ cam kết với điều đó. Gần đây, người quản lý phát triển đã bắt đầu một kho lưu trữ thứ hai hoạt động như "thẻ" của chúng tôi, nhưng nó phải được hợp nhất thủ công với "thân cây" vì nó không phải là một phần của cùng một kho lưu trữ mà là một kho hoàn toàn riêng biệt. Trên thực tế, chỉ có một thư mục, được gọi là "Dev" (thực sự có các thư mục "Dev" khác nhau vào các ngày khác nhau nhưng chỉ "Dev" là thư mục chính) và dưới đó là mọi thứ khác; Tất cả các dự án khác. Nó hoàn toàn không được tổ chức bởi dự án, nó không có khái niệm về nhánh / thẻ / thân cây hay bất cứ thứ gì. Người thiết lập ban đầu (đã qua lâu rồi, tất nhiên) dường như không biết cách thiết lập SVN, và kể từ đó, không ai bận tâm học cách làm mọi thứ đúng cách vì sợ phá vỡ thứ gì đó. Chúng tôi không sử dụng bất kỳ loại CI nào (hoặc thử nghiệm tự động, không may).

Đầu tiên, chúng ta có nên tách nó theo dự án không? Chẳng hạn, chúng ta có: Hai trang web ASP.NET (không phải Ứng dụng web, Trang web), Dịch vụ web, thư mục triển khai cho tất cả các tập lệnh bảng và quy trình được lưu trữ, hai máy khách dòng lệnh cho các dự án bên ngoài được gọi bởi WebSites và một thư mục chia sẻ có các đối tượng kinh doanh phổ biến và tương tự. Mỗi người trong số họ nên là dự án của riêng họ với thiết lập nhánh / thẻ / thân cây hoặc nên như thế này:

dev/
  branches/
  tags/
  trunk/
      Site1/
      Site2/
      WebService/
      SharedCode/

và có tất cả các nhánh và mọi thứ có một bản sao của toàn bộ thư mục Dev không? Cách tiếp cận đó có thể dễ nuốt hơn vì chúng ta thường có những tình huống cần thay đổi trong thư viện mã được chia sẻ và ít nhất một (thường là cả hai) các trang web.

Thứ hai, chúng tôi phát hành thường xuyên ("đẩy" theo cách nói của chúng tôi) đến máy chủ dev và máy chủ trực tiếp của chúng tôi. Từ những gì tôi đã đọc cách tốt nhất để xử lý điều này sẽ là tất cả sự phát triển đi vào thân cây /, các nhánh là "tạm thời" và được sử dụng để thêm một tính năng mới có thể ảnh hưởng đến trung kế và các thẻ được phát hành? Vì vậy, chúng tôi thúc đẩy mỗi tháng, hãy nói và tôi đang làm việc trên một mô-đun hoàn toàn mới. Tôi sẽ phân nhánh trung kế và sử dụng nhánh đó cho mã của mình, viết và kiểm tra nó và bất cứ điều gì. Khi mô-đun hoàn thành, tôi sẽ hợp nhất nó trở lại vào thân cây (và có thể xóa chi nhánh) và khi chúng tôi sẵn sàng triển khai, chúng tôi sẽ gắn thẻ nó ("May2011" giả sử). Nếu chúng tôi có một sửa lỗi sau khi nó đi vào hoạt động, nó sẽ được sửa trong thẻ tháng 5 năm 2011 và được hợp nhất vào thân cây (vì vậy thân cây cũng được sửa chữa), và sau đó tháng 5 năm 2011 sẽ được đẩy ra một lần nữa với bản sửa lỗi? Đây có phải là ý định gắn thẻ?


5
Chiến lược bên ngoài hộp: chuyển sang git.
Rein Henrichs

Nếu đó là một lựa chọn, tôi sẽ thực hiện nó (hoặc Mercurial, vì chúng tôi là một cửa hàng Windows). Tôi nghĩ rằng tôi sẽ phải đối mặt với nhiều sự kháng cự hơn khi cố gắng chuyển sang một hệ thống kiểm soát nguồn hoàn toàn mới hơn là cố gắng ít nhất là có được một môi trường phù hợp được thiết lập với SVN.
Wayne Molina

2
Mặc dù tôi rất hào hứng với DVCS, Subversion là một công cụ tốt. CVS hoặc giải pháp khác mà không có phiên bản thư mục sẽ tồi tệ hơn.
Matthew Rodatus

2
@Wayne M - Bạn có thể thấy nó thực sự khác. Có thể dễ dàng hơn để khiến mọi người đăng ký vào một cấu trúc môi trường hợp lý hơn nếu làm như vậy sẽ mang lại cho họ tất cả những lợi thế của việc sử dụng DVCS. Là một quá trình chuyển đổi, bạn có thể muốn xem xét việc đưa người dùng thử truy cập phân nhánh / repo cục bộ giá rẻ bằng cách sử dụng gitsvn hoặc chuyển đổi hksubversion. Khi chúng được nối và sử dụng các công cụ, có thể có một mong muốn rộng rãi của nhóm để chuyển sang DVCS cho (các) repo chính.
Đánh dấu gian hàng

Câu trả lời:


5

Nếu bạn muốn một quy trình xây dựng thống nhất, thì hãy chắc chắn đặt các nhánh / thẻ / thân cây ở gốc, như thế này:

branches/
tags/
trunk/
  dev/
    ...

Nếu bạn không cần một quy trình xây dựng thống nhất, thì bạn có thể đặt các nhánh / thẻ / thân trong mỗi dự án nếu bạn muốn. Tuy nhiên, có thể khó chuyển sang một bản dựng thống nhất sau khi đã đặt chúng trong mỗi dự án. Một bản dựng hợp nhất có những lợi thế, như loại bỏ nhu cầu xuất bản các thành phần được chia sẻ giữa các dự án - chúng đều là một phần của bản dựng.

Cá nhân, tôi thích một quá trình xây dựng thống nhất. Hơn nữa, tôi không nghĩ bạn nên có một dự án "dev". Bạn nên có các dự án trực tiếp dưới thân cây, và sau đó phân nhánh thân cây thành một nhánh dev. Sử dụng thẻ để phát hành. Ví dụ, tôi sẽ làm như thế này:

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/

1
Một bản dựng hợp nhất có những lợi thế, như loại bỏ nhu cầu xuất bản các thành phần được chia sẻ giữa các dự án - chúng đều là một phần của bản dựng.
Matthew Rodatus

2
Nếu bạn cần nhiều bản dựng hợp nhất, sau đó tạo thư mục trong thân cây cho mỗi bản dựng. Nhưng, tôi sẽ không đặt tên cho một "dev" - điều đó hoàn thành tốt hơn với một nhánh. Ví dụ: bạn có thể có hai tổ chức phát triển chính - một tổ chức hoạt động trên trình điều khiển thiết bị và một tổ chức hoạt động trên trang web của công ty. Bạn có thể muốn hai bản dựng thống nhất riêng biệt.
Matthew Rodatus

1
  1. Theo như cấu trúc mã trong svn thì đây thực sự là lựa chọn cá nhân.

Tôi sẽ đề nghị rằng nếu các dự án có liên quan hoặc chia sẻ mã thì họ muốn có một thân cây chung. Nếu chúng độc lập thì chúng muốn các thân riêng biệt hoặc thậm chí là các kho riêng biệt. Nếu bạn cần cung cấp cho bên thứ ba một bản sao của lịch sử svn cho một dự án thì sẽ dễ dàng hơn nhiều nếu nó nằm trong một kho lưu trữ riêng biệt.

Vì vậy, trong trường hợp của bạn, có vẻ như bố cục bạn đã phác thảo ở trên sẽ hợp lý, vì bạn đã chia sẻ mã và bạn muốn các nhánh / thẻ bao gồm mã được chia sẻ đó.

  1. Mô tả của bạn về thẻ và chi nhánh sử dụng âm thanh rõ ràng hợp lý và là cách tôi mong đợi svn sẽ được sử dụng. Đó thực sự là ý định gắn thẻ khi tôi hiểu nó. BTW trong các thẻ svn và các nhánh thực sự giống nhau, nhưng thuật ngữ được áp dụng như bạn đã áp dụng nó.

Cá nhân tôi cũng sẽ thêm lời cảnh báo rằng bất cứ điều gì cam kết với thân cây phải được xây dựng, phải là nguyên tử và không nên phá vỡ bất kỳ bài kiểm tra đơn vị nào. Chi nhánh dành cho công việc còn dang dở. Tôi hy vọng thân cây sẽ là một ứng cử viên phát hành tiềm năng tại bất kỳ thời điểm nào.


Bạn đang nói rằng chỉ có mã thử nghiệm, sẵn sàng sản xuất nên ở trong thân cây? Tôi nghĩ rằng bất kỳ mã nào được cam kết nên xây dựng và có thể vượt qua các bài kiểm tra, và mã thân tất nhiên phải vượt qua các bài kiểm tra. Nhưng có vẻ như mục đích của SVN là có thể theo dõi lịch sử phát triển và điều đó dễ dàng hơn nếu nó không được phân chia thành nhiều nhánh. Có lẽ nên có một nhánh mà bạn hợp nhất thân cây vào khi thân cây ở trạng thái sẵn sàng sản xuất?
Ông Jefferson

0

Sau đây là cách tốt nhất để bố trí kho Subversion

project_a
     - branches
     - tags
     - trunk
project_b
     - branches
     - tags
     - trunk
project_c
     - branches
     - tags
     - trunk
master
     - branches
     - tags
     - trunk       
         - svn:external project_a
         - svn:external project_b
         - svn:external project_c

Bằng cách này bạn có thể tự kiểm tra các dự án cá nhân.

Nếu bạn muốn kiểm tra tất cả 3 dự án và thực hiện thống nhất xây dựng với một số xây dựng kịch bản / hệ thống nguyên khối sau đó điều tra sử dụng một bậc thầy mô-đun với svn: externals lập bản đồ tất cả các dự án khác vào bậc thầy trunk .

Điều này phức tạp hơn thoạt nhìn nhưng nó là cách dễ duy trì và thành ngữ nhất để giải quyết vấn đề này với Subversion.


2
Tôi rất không đồng ý. Các kho lưu trữ không chỉ là mã lưu trữ; nó truyền đạt cấu trúc tổ chức và mối quan hệ giữa các thành phần; nó là một kênh truyền thông quan trọng, mặc dù ngầm. Nếu bạn tách từng dự án ra một cách riêng biệt thì bạn đang đưa ra những rào cản nhân tạo và không cần thiết cho truyền thông.
William Payne
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.