Nhiều hệ thống kiểm soát phiên bản đồng thời?

Question

Tôi tương đối mới với điều khiển phiên bản, và cho đến nay chỉ có kinh nghiệm làm việc với Subversion bằng cách sử dụng TortoiseSVN/VisualSVN. Tôi đã đọc về các loại VCS khác (git, mercurial, vv), và đang cân nhắc việc thử chúng - tuy nhiên, nhiều lập luận cho hay chống lại một VCS cụ thể có vẻ như chúng chủ yếu đi đến sở thích chủ quan, vì vậy tôi ' sẽ có thể gió lên cho mỗi người một cái nhìn.

Khi suy nghĩ về cách làm như vậy, tôi đã tự hỏi nếu nó thậm chí về mặt lý thuyết có thể sử dụng nhiều VCS trên một codebase duy nhất. Mà (nếu có) kết hợp của VCS có thể đây là một khả năng? Và nếu có thể, bao nhiêu cơn ác mộng hậu cần sẽ cố gắng sắp xếp các danh sách loại trừ tương ứng?

Một đối số có thể có để làm như vậy có thể là dự phòng dự phòng. Một số nhà cung cấp VCS (Beanstalk, Github, Bitbucket) cung cấp một kho lưu trữ miễn phí, vì vậy bạn có thể có cùng một repo được sao lưu miễn phí ở nhiều nơi khác nhau.

Answer 1

Chắc chắn, điều này là có thể, thậm chí phổ biến trong một số trường hợp. Ví dụ: git và svn là một cặp tự nhiên cho việc này. Trường hợp sử dụng chuẩn là một tổ chức phải có kho lưu trữ Subversion trung tâm kế thừa vì nhiều lý do khác nhau, nhưng trong đó các nhà phát triển muốn sử dụng Git để tăng năng suất mà nó cung cấp.

Nhập git-svn. Bây giờ các nhà phát triển đẩy và kéo từ repo Git địa phương của riêng họ đến kho lưu trữ Subversion trung tâm, nhưng vẫn nhận được tất cả sức mạnh tuyệt vời của Git. Quá trình này là hoàn toàn và hoàn toàn minh bạch cho kho lưu trữ Subversion, mà chỉ đơn giản là nhìn thấy những thay đổi được đẩy vào nó.

Answer 2

Thường thì khó (nhưng không phải là không thể) để xử lý nhiều VCS trên một codebase. Tuy nhiên, bạn sẽ có khả năng gặp sự cố khi xóa tệp ... Đôi khi, một VC sẽ không nhận ra tệp đã bị xóa.

Tuy nhiên, tôi không đề xuất điều này. Hầu hết VC sử dụng các tệp trong codebase để theo dõi các thay đổi. Có nhiều hệ thống VC tại chỗ sẽ gây ô nhiễm hệ thống tệp của bạn với nhiều tệp có khả năng gây ra sự cố trong các VC khác.

Answer 3

Tôi biết nó không hoàn toàn sử dụng nhiều VCS, nhưng có thể một số VCS có các giao diện người dùng khác nhau. Git, ví dụ, có thể có một mặt trước SVN để các SVN client có thể sử dụng kho Git (và chúng sẽ không có gì khôn ngoan hơn cả Git). Tôi nghĩ rằng cũng có các giao diện người dùng khác có sẵn cho nó.

Answer 4

Mercurial (với hgsubversion), git (với git-svn) và bzr (bzr-svn) tất cả đều có tùy chọn đồng bộ hóa với kho lưu trữ svn ngược dòng.

Vì vậy, nó đã có thể (giả sử các phần mở rộng hoạt động đủ tốt) để tương tác với một kho svn với differents SCM.

Answer 5

Chắc chắn là có thể làm được điều này. Tôi sử dụng git-svn để cập nhật kho lưu trữ git cục bộ của mình và cam kết vào kho lưu trữ svn của công ty. Với bất kỳ công cụ VCS nào mà bạn sẽ quyết định sử dụng, vấn đề mà bạn sẽ gặp phải nhất là trong khi cập nhật kho lưu trữ cục bộ của bạn với những thay đổi từ kho lưu trữ từ xa.

Nếu bạn sử dụng bazaar cho kho lưu trữ cục bộ của mình, the most problematic thing là khi kho lưu trữ bazaar cục bộ của bạn được phân tách và bạn muốn cam kết với kho lưu trữ từ xa của mình. Đôi khi bạn phải làm "đẩy ghi đè" để giải quyết.

Tôi không gặp phải sự cố "kho lưu trữ được phân tách" này khi sử dụng git-svn để cập nhật kho lưu trữ git cục bộ của mình với các thay đổi từ kho lưu trữ svn từ xa.Nhưng đôi khi tôi làm "git svn rebase" nó sẽ có xung đột và nếu không làm thủ tục để giải quyết nó, bạn có thể dành rất nhiều thời gian. Bởi vì tôi đã gặp phải điều này hơn và hơn nữa, tôi có documented it và tôi không tìm thấy nó như một vấn đề lớn bây giờ.

Answer 6

Phản hồi đầu tiên của tôi khi tôi đọc câu hỏi của bạn là "Chắc chắn, về mặt kỹ thuật có thể, nhưng thực sự là một ý tưởng tồi."

Tôi sẽ quay lại một chút sau khi xem các nhận xét khác. Được rồi, mỗi người dùng có thể có một kho lưu trữ cục bộ tách biệt khỏi kho lưu trữ trung tâm và sử dụng nó để giữ cơ bản các trạm kiểm soát khi làm việc. Trong trường hợp đó, họ có thể hoàn toàn tách biệt VCS và nó sẽ không thành vấn đề.

Nhưng nếu bạn đang nghĩ đến hai VCS khác nhau đồng thời giữ kho lưu trữ trung tâm của bạn, điều đó có thể thực hiện công nghệ, nhưng thực sự là một ý tưởng tồi. Toàn bộ điểm của VCS là bạn duy trì lịch sử của tất cả các thay đổi được thực hiện cho các tệp, bạn có thể xem những thay đổi nào được thực hiện khi và - nếu người dùng đưa ra nhận xét phong nha một nửa về cam kết - tại sao. Nếu một khách hàng có phiên bản ngày 19 tháng 6 năm 2007 có vấn đề, bạn có thể lấy mã chính xác như đã tồn tại vào ngày 19 tháng 6 năm 2007, vì vậy bạn đang gỡ lỗi mã mà người dùng thực sự đang chạy. Nếu bạn phát hiện ra sự thay đổi mới nhất là một sai lầm lớn, bạn có thể quay trở lại. V.v ...

Nhưng nếu bạn có hai kho lưu trữ ... Bạn sẽ thực hiện mọi cam kết giống hệt nhau cho cả hai kho lưu trữ? Ít nhất đó là một loạt các công việc phụ. Tệ nhất, sớm hay muộn ai đó sẽ phạm sai lầm, quên cam kết một hoặc không cam kết cho đến ngày hôm sau sau khi người khác đã thực hiện một cam kết can thiệp, và các kho sẽ không thực sự giống hệt nhau. Hoặc bạn sẽ thay thế, đôi khi kiểm tra ra khỏi A và đôi khi ra khỏi B? Nhưng sau đó không ai sẽ biết những gì trong một trong hai.

Tôi có thể thấy bằng cách sử dụng hai VCS khác nhau trong vài ngày hoặc vài tuần để thử xem chúng hoạt động như thế nào, cảm nhận bạn thích tốt hơn. Nhưng ngay cả khi đó, tôi sẽ không làm điều đó như hệ thống sản xuất của mình. Tôi có VCS sản xuất thực sự, và sau đó là một cái khác ở bên mà chúng tôi chơi nhưng không ai coi là có thẩm quyền.