Chúng tôi là Subversion Geek và chúng tôi muốn biết lợi ích của Mercurial [đã đóng]

Đã đọc Tôi là một người đam mê Subversion, tại sao tôi nên xem xét hoặc không xem xét Mercurial hoặc Git hoặc bất kỳ DVCS nào khác .

Tôi có một câu hỏi tiếp theo liên quan. Tôi đọc câu hỏi đó và đọc các liên kết và video được đề xuất và tôi thấy những lợi ích nhưng tôi không thấy những người suy nghĩ tổng thể đang nói về.

Nhóm của chúng tôi gồm 8-10 nhà phát triển làm việc trên một cơ sở mã lớn bao gồm 60 dự án. Chúng tôi sử dụng Subversion và có một thân cây chính. Khi một nhà phát triển bắt đầu một trường hợp Fogormsz mới, họ tạo một nhánh svn, thực hiện công việc trên nhánh đó và khi hoàn thành, họ hợp nhất trở lại thân cây. Đôi khi, họ có thể ở lại chi nhánh trong một thời gian dài và hợp nhất thân cây với chi nhánh để nhận các thay đổi.

Khi tôi xem Linus nói về những người tạo ra một chi nhánh và không bao giờ làm lại, đó không phải là chúng tôi. Chúng tôi có thể tạo ra 50-100 chi nhánh một tuần mà không có vấn đề. Thách thức lớn nhất là sáp nhập nhưng chúng tôi cũng đã đạt được điều đó khá tốt. Tôi có xu hướng hợp nhất bởi trường hợp sương mù & checkin hơn là toàn bộ gốc của nhánh.

Chúng tôi không bao giờ làm việc từ xa và chúng tôi không bao giờ làm cho các chi nhánh ra khỏi chi nhánh. Nếu bạn là người duy nhất làm việc trong phần đó của cơ sở mã thì việc hợp nhất với trung kế diễn ra suôn sẻ. Nếu ai đó đã sửa đổi cùng một phần mã thì việc hợp nhất có thể trở nên lộn xộn và bạn có thể cần phải thực hiện một số phẫu thuật. Xung đột là xung đột, tôi không thấy làm thế nào bất kỳ hệ thống nào có thể làm cho nó đúng hầu hết thời gian trừ khi nếu đủ thông minh để hiểu mã.

Sau khi tạo một nhánh, việc kiểm tra các tệp 60k + sau đây sẽ mất một chút thời gian nhưng đó sẽ là một vấn đề với bất kỳ hệ thống kiểm soát nguồn nào chúng tôi sử dụng.

Có một số lợi ích của bất kỳ DVCS nào mà chúng ta không thấy sẽ giúp ích cho chúng ta không?

Để viết lại câu hỏi của bạn, "Nếu chúng tôi dự định chỉ sử dụng DVCS theo cách tập trung, thì nó có lợi ích gì?" Khi bạn hỏi nó theo cách đó, nó không. Một nhánh cho mỗi nhiệm vụ là cực kỳ phổ biến trong VCS. Nếu bạn nghĩ về nó, có một bản sao mã nguồn hoạt động cục bộ trên máy của nhà phát triển thay đổi độc lập với thân cây trong một ngày là một nhánh, mặc dù không ai gọi nó là mã đó. Sự khác biệt duy nhất giữa điều đó và quy trình công việc của bạn là bạn đang đặt cho các nhánh đó một tên cố định trên máy chủ trung tâm. Đó không phải là loại phân nhánh mà Linus và những người khác đang nói đến.

Để hiểu DVCS đòi hỏi một sự thay đổi cơ bản trong suy nghĩ. Bạn phải tự hỏi mình sẽ làm gì với bao nhiêu chi nhánh mà bạn muốn được chia sẻ với bất kỳ ai bạn muốn, và chỉ họ. Điều đó bao gồm các chi nhánh chỉ được nhìn thấy bởi chính bạn.

Các khả năng là vô tận. Chỉ với một ví dụ, làm thế nào về hai người làm việc ở hai phía đối diện của một giao diện? Họ cần chia sẻ mã với nhau thường xuyên, nhưng chưa đủ ổn định để chia sẻ với mọi người. Họ có thể tạo một nhánh để chia sẻ với nhau, sau đó hợp nhất nó trở lại vào kho lưu trữ trung tâm khi nó sẵn sàng.

Khả năng thực hiện các cam kết địa phương trung gian là hoàn toàn xứng đáng. Đó là điều bạn chỉ cần tự mình trải nghiệm.

Tốc độ đạt được từ việc có repo cục bộ của bạn cũng đáng giá như vậy. Có, bản sao ban đầu sẽ chậm không thể tránh khỏi trong bất kỳ VCS nào cho repo tệp 60k, nhưng một khi bạn đã có, kiểm tra một nhánh mới là các đơn đặt hàng có cường độ nhanh hơn với DVCS.

Đối với trường hợp cụ thể của bạn, không có lợi ích khi chuyển sang DVCS. Bạn hài lòng với hệ thống hiện tại của mình, nó làm mọi thứ bạn cần, vậy tại sao lại chuyển đổi? SVN vẫn là một dự án nguồn mở đang hoạt động và có các tích hợp tốt hơn, trưởng thành hơn với tất cả các IDE và công cụ phát triển chính so với hg hoặc git. Với quy mô của nhóm của bạn và số lượng dự án, bạn có thực sự muốn dành thời gian để chuyển đổi sang một công cụ mới khi công cụ hiện tại đang hoạt động tốt không?

Nếu bạn có các nhà phát triển không thể hoạt động mà không có DVCS, hãy trỏ họ đến các cổng svn cho hg hoặc git. Hãy nói rõ với họ rằng các đăng ký của họ đối với kho svn phải tuân thủ mọi quy trình và quy trình còn lại của nhóm sử dụng. Một ưu điểm khác của phương pháp này là những người nhiệt tình DVCS thực sự đã sử dụng các cổng mà không cho bạn biết bây giờ có thể ra khỏi tủ :-).

Dường như với tôi rằng bạn đã sử dụng một quy trình công việc rất giống với quy trình công việc mà nhiều người áp dụng sau khi họ bắt đầu sử dụng DVCS.

Theo quan điểm của bạn, một DVCS sẽ có những lợi thế đáng kể sau SVN:

• Khi bạn đã nhân bản (các) repo của mình, nhiều thao tác có thể được thực hiện cục bộ.
  • Nhìn vào nhật ký kho lưu trữ không cần phải chạm vào máy chủ svn, vì vậy có thể cực kỳ nhanh.
  • Tương tự, các nhánh chuyển đổi không yêu cầu quyền truy cập vào máy chủ, cũng như không nhân bản cục bộ.
• Bởi vì các nhánh chỉ là các đường dẫn khác nhau trong lịch sử, kho lưu trữ của bạn không bị lộn xộn với mọi nhánh mà mọi người đã tạo (chúng tôi chỉ thực sự có các nhánh phát hành trong SVN, nhưng branchesthư mục vẫn có nhiều thư mục con không còn phù hợp).
  • Trong git, một khi một nhánh đã được hợp nhất trở lại và ref bị xóa, bạn có thể không bao giờ biết nó còn ở đó.
  • Trong Mercurial, bạn có thể chọn đặt tên một nhánh (trong trường hợp đó, nó được mã hóa thành từng thay đổi vĩnh viễn) hoặc chỉ tạo một nhánh (tôpô) không tên, sẽ lặng lẽ hợp nhất vào lịch sử khi nó mergequay trở lại default( trunk)
• Trong SVN, các nhánh của các chi nhánh quá tối nghĩa là không hữu ích. Trong gitvà hghọ chỉ là mệnh cho khóa học.
• DVCS 'hiểu rằng phát triển phần mềm là một DAG , tức là khi bạn hợp nhất, bạn kết thúc với một bộ thay đổi có nhiều cha mẹ. SVN (ít nhất là phiên bản tôi đã sử dụng) không thực sự hiểu điều này.

Về điểm cuối cùng, bạn nói

Xung đột là xung đột, tôi không thấy bất kỳ hệ thống nào có thể làm cho nó đúng trong hầu hết thời gian trừ khi nó đủ thông minh để hiểu mã.

Trong chuyển đổi từ việc sử dụng hgđộc quyền để sử dụng svnmột mình và sau đó gitsvnnó đã được kinh nghiệm của tôi rằng hòa trộn là nhiều đơn giản hơn và rắc rối miễn phí với hgvà gitsvnhơn những gì họ đang có svn. Việc hợp nhất với svn(ít nhất là phiên bản chúng tôi sử dụng) tạo ra nhiều xung đột hơn đáng kể cần được giải quyết bằng tay.

Một trong những lý do khiến việc sáp nhập trở nên khó khăn hơn trong SVN là nó chỉ cung cấp cho bạn hai tùy chọn cho mỗi dòng khác nhau,

• văn bản từ chi nhánh mà bạn đang hợp nhất
• văn bản từ chi nhánh mà bạn đang hợp nhất vào

trong khi việc hợp nhất từ ​​DVCS thường sẽ cung cấp cho bạn tùy chọn thứ ba, đó là

• văn bản từ tổ tiên chung của cả hai nhánh mà bạn đang hợp nhất

Đừng đánh giá thấp như thế nào có lợi này là, nó cung cấp cho bạn với nhiều bối cảnh tốt hơn cho những thay đổi so với một cách khác đơn giản hai có thể.

Tất cả trong tất cả, tôi sẽ đề nghị bạn hãy thử xem. Với các công cụ như gitsvnvà hgsubversion, bạn thậm chí có thể dùng thử chúng với các repos SVN hiện tại của bạn .

^{Lưu ý, tạo bản sao ở vị trí đầu tiên là một PItA hoàng gia, nhưng một khi bạn đã làm điều đó, bạn sẽ nhận được hầu hết sức mạnh của một DVCS với CVCS hiện tại của bạn.}

Có một thay đổi quan trọng mà tôi nhận thấy sau khi chuyển đổi như vậy: Tôi chuyển đổi chi nhánh thường xuyên hơn và tôi cam kết thường xuyên hơn mức tôi có thể chi trả với Subversion. Ví dụ, có một số nhánh chức năng nhỏ, được sắp xếp theo trình tự và tôi có thể dành hàng tháng để thêm bit cho mỗi nhóm, dễ dàng chuyển đổi tất cả chúng thành một thân cây luôn thay đổi. Sắp xếp lại thứ tự các nhánh chức năng được hợp nhất là chuyện nhỏ.

Nhưng, trên thực tế, tôi đã không thực sự rời khỏi Subversion. Tôi chỉ sử dụng git làm khách hàng svn địa phương của tôi.