Bạn sẽ giải thích những rủi ro của từ khóa $ Log $ như thế nào?

Question

Tôi dường như tham gia vào một cuộc tranh luận hàng năm về việc sử dụng từ khóa $Log$. Quan điểm của tôi là:

$Log$ là màu trắng chết nóng.

Tất cả những gì bạn làm là spam có liên quan đến thư rác trong tệp nguồn của bạn. Bất kỳ thông tin nào mà bất kỳ ai nghĩ rằng họ có thể nhận được từ $ Log $ đều sẵn sàng hơn (và có khả năng chính xác hơn) trong hệ thống kiểm soát phiên bản của bạn. Vì vậy, đây là câu hỏi: làm thế nào bạn sẽ giải thích cho một coder "trường học cũ" (những người nghĩ rằng $ Log $ là cách để quản lý thay đổi mã nguồn) mà chúng tôi có các công cụ tốt hơn bây giờ không? Có phải không?

The CVSNT remarks on $Log$ are a good start nhưng chúng không chỉ đủ. Cho đến nay, gần nhất mà tôi đã đến một lớp lót mà tôi đã xoay xở để tìm ra là "$Log$ là một điều ước. Bạn đang hy vọng rằng nội dung bị spam vào tệp của bạn có bất kỳ mối quan hệ nào những gì thực sự xảy ra với tập tin này. "

PS cho rõ ràng: khi tôi nói "trường học cũ", tôi có nghĩa là cũ trong thái độ, không già trong năm. Tiền lương lập trình đầu tiên của tôi (và một khoản tiền đáng chú ý mà nó cũng vậy) là đôi khi vào năm 1986 và tôi không bao giờ nghĩ rằng $ Log $ là một ý tưởng hay.

Answer 1

Tôi nghĩ rằng Subversion FAQ cũng có giải thích tốt.

$ Nhật ký $ là tổng số kinh dị khi bạn bắt đầu hợp nhất các thay đổi giữa các chi nhánh. Bạn thực tế được bảo đảm để có xung đột ở đó, - vì tính chất của từ khóa này - chỉ đơn giản là không thể được giải quyết tự động.

Answer 2

Ngoài những gì người khác đã nói, hãy thử đặt nhận xét (/ * ... * /) vào thông báo cam kết: ->.

Answer 3

Số lượng bit hữu ích trong tệp nguồn từ từ giảm khi các thay đổi được thực hiện cho nó với câu lệnh $ Log $ đó. Chúng tôi đã có nó trong một số tập tin đến từ CVS và số dòng $ $ $ báo cáo là trên thứ tự của 10x dài hơn so với mã thực thi trong tập tin thực sự được. Và nó có một vài nhóm trùng lặp do sự hợp nhất xấu từ một số chi nhánh.

Answer 4

Bạn có thể xem xét (nhấn mạnh vào có thể) nhúng không thay đổi siêu dữ liệu trong tệp của bạn.
(Xem cuộc tranh luận giữa tôi và "học sinh lớn tuổi": Embedded Version Numbers - Good or Evil?).

Mặc dù tôi luôn coi hành vi đó là xấu (trộn thông tin siêu dữ liệu vào dữ liệu), giới thiệu "hợp nhất địa ngục", người ta có thể cho rằng nó có thể hoạt động, với trình quản lý hợp nhất phù hợp, cho siêu dữ liệu không thay đổi với một định dạng cố định, như:

• $ Revision $ $ Revision: 9.13 $
• $ ngày $ $ ngày: 2009/03/06 06:52:26 $
• $ RCSfile $ $ RCSfile : stderr.c, v $

Nhưng siêu dữ liệu có thể thay đổi như nhật ký? Với định dạng hoặc nội dung không xác định? Điều đó nhất định thất bại.