TFS: Nhãn vs Thay đổi

Question

Tôi đang cố gắng đưa ra các phương pháp hay nhất liên quan đến việc sử dụng điều khiển nguồn TFS. Ngay bây giờ, bất cứ khi nào chúng ta xây dựng, chúng tôi gắn nhãn các tệp được kiểm tra vào TFS với số phiên bản. Cách tiếp cận này tốt hơn hay tệ hơn là chỉ kiểm tra các tệp và có số phiên bản trong các nhận xét? Sau đó, bạn có thể sử dụng changeset để quay lại nếu cần hoặc nhãn vẫn linh hoạt hơn?

Cảm ơn!

Answer 1

Chúng có hai mục đích khác nhau, ChangeSets là khi các tệp đã thực sự thay đổi và bạn muốn lưu giữ hồ sơ vĩnh viễn về thay đổi đó. Nhãn đánh dấu một phiên bản nhất định của các tệp để bạn có thể dễ dàng quay lại điểm đó. Trừ khi xây dựng của bạn thực sự thay đổi tập tin dưới sự kiểm soát nguồn và bạn muốn ghi lại những thay đổi này. Bạn nên ghi nhãn.

Ngoài ra, việc ghi nhãn ít tốn kém tài nguyên hơn nhiều. Và bạn có thể có nhiều nhãn trên cùng một phiên bản của một tệp.

Answer 2

Ngay bây giờ, bất cứ khi nào chúng ta làm một xây dựng, chúng ta gọi các tập tin được kiểm tra vào TFS với số phiên bản

Bạn không cần phải làm điều này. TFS có thể tham chiếu đến một trạng thái của codebase theo nhiều cách, trong đó các nhãn thực sự là một - nhưng như vậy là xây dựng và thậm chí cả các thay đổi. Bạn có thể xem cách sẵn để tái tạo lại một điểm cụ thể trong thời gian bằng cách làm một Get Specific Version... và kiểm tra các tùy chọn trong Type thả xuống:

Changeset 
Date 
Label 
Latest Version 
Workspace Version 

Changeset cho phép bạn để có được ngay sau khi bất kỳ changeset; Date là hiển nhiên; Label cũng vậy, ngoại trừ việc xây dựng tự động * tạo nhãn (chọn Label từ trình đơn thả xuống này sau đó có giao diện trong hộp thoại Find Label).

* Tôi nghĩ nó tự động! Trừ khi đó là điều chúng tôi đã thiết lập đặc biệt ở thời điểm hiện tại ...

Answer 3

Bạn nên gắn nhãn các phiên bản của tệp nguồn tạo nên bản dựng của mình. Nếu bạn đang sử dụng TeamBuild, nó sẽ tự động thực hiện điều đó. Nó kết hợp tên của định nghĩa xây dựng, ngày tháng và số bản dựng của bạn. Vì vậy, bạn không cần phải làm bất cứ điều gì.

Tùy chọn khác của bạn không phải là rất thông thường và đòi hỏi nhiều công việc không cần thiết. Nếu tôi hiểu chính xác, bạn sẽ kiểm tra các tệp nguồn của mình trong quá trình xây dựng và sau đó kiểm tra lại chúng bằng số phiên bản được chỉ định trong các nhận xét đăng ký. Đây là như Alex đã đề cập rất tài nguyên chuyên sâu về quá trình xây dựng của bạn và cũng là kho kiểm soát nguồn của bạn. Hơn nữa, làm thế nào bạn sẽ nhận được các tập tin nguồn cho một phiên bản cụ thể nếu thông tin phiên bản được nhúng trong các ý kiến? Nó sẽ rất khó và bạn sẽ phải ngồi xuống và viết ứng dụng của riêng bạn sử dụng api kiểm soát nguồn TFS để tải các tệp nguồn xuống một vùng làm việc bằng cách tìm kiếm số phiên bản trong các nhận xét check-in. Điều này tạo ra sự phức tạp và đau đầu không cần thiết.

Nếu bạn sử dụng nhãn thay vào đó, bạn có thể thực hiện nhận theo nhãn trong VS IDE để tải xuống tệp nguồn tạo nên nhãn đó. Thậm chí bạn có thể yêu cầu TeamBuild sử dụng nhãn thay vì tải xuống các tệp nguồn mới nhất trong quá trình tự động hóa xây dựng. Bằng cách đó bạn có thể dễ dàng xây dựng các phiên bản ứng dụng trước. Với nhãn, bạn cũng có thể áp dụng các thay đổi sau đó cho nhãn hiện tại nếu có thay đổi mã bằng cách đơn giản nhận nhãn đó và sau đó nhận các thay đổi cụ thể và sau đó tạo nhãn nhanh hoặc tạo nhãn mới.

Ghi nhãn rất mạnh, thuận tiện để sử dụng và là một phần của TFS. Thay vì đến với giải pháp tùy chỉnh của bạn đòi hỏi rất nhiều nỗ lực để làm cho nó hoạt động và duy trì, chỉ cần cố gắng sử dụng những gì đã có sẵn.

Answer 4

StackOverflow sẽ không cho phép tôi nhận xét về các câu trả lời ở trên, vì vậy tôi đang viết câu trả lời này dưới dạng "câu trả lời" mới. Tôi muốn làm rõ một số quan niệm sai lầm được liệt kê ở trên.

Trước tiên, việc sử dụng Nhãn TFVC là nguồn tài nguyên THÊM nhiều hơn sử dụng changesets. Hơn rất nhiều. Các lệnh như Branch, Merge và Get by Label chậm hơn. Đối với các máy chủ doanh nghiệp có cơ sở dữ liệu khổng lồ, bạn không muốn sử dụng nhãn.

Thứ hai, Bản dựng không tự động tạo nhãn, mặc dù các bước xây dựng mặc định bao gồm một bước để tạo nhãn.

Thứ ba, như những người khác đã đề cập, nhãn có thể được di chuyển hoặc xóa, vì vậy chúng ít đáng tin cậy hơn so với các thay đổi không thay đổi.

Nói chung, tôi khuyên bạn KHÔNG nên sử dụng nhãn. Cách thay thế đơn giản nhất là chỉ nhớ số thay đổi cho các bản dựng của bạn. Hoặc nếu bạn muốn tách biệt các phiên bản phát hành khác nhau, bạn nên tạo các nhánh phát hành.

Nhãn là OK cho các hệ thống nhỏ, nhưng không tốt cho các doanh nghiệp lớn.