Hệ thống kiểm soát phiên bản yêu thích của bạn là gì? [đóng cửa]

Đây là một câu hỏi thảo luận nhiều hơn là một nỗ lực thực tế để xác định "tốt nhất", vì điều đó thay đổi rõ ràng theo nhu cầu của tổ chức. Tôi tò mò hơn về các đối số có lợi cho các hệ thống khác nhau trên các danh mục (tập trung so với phân phối, mở so với độc quyền, v.v.).

Vì vậy, bạn nghĩ gì là hệ thống kiểm soát phiên bản tốt nhất?

Không kiên định

Do khả năng phân nhánh và hợp nhất mã phức tạp, đây là cách tốt nhất tôi đã sử dụng. Toàn bộ mô hình DVCS chỉ có ý nghĩa rất nhiều. Tôi đã không sử dụng Git, nhưng tôi cho rằng nó cũng đủ điều kiện.

Git

Git thật tuyệt vời và tôi đặc biệt muốn giới thiệu nó cho bất kỳ ai làm việc trong các dự án nguồn mở: việc đóng góp một thay đổi nhỏ, một lần cho một dự án trên Git, đặc biệt là nếu nó được lưu trữ trên GitHub, hơn là giao dịch với e- gửi bản vá về SVN.

Một cảnh báo lớn cho người dùng Windows: Các công cụ Windows của Git, mặc dù chắc chắn có thể sử dụng được, nhưng không hoàn toàn khó hiểu. Khi tôi buộc phải sử dụng Windows một thời gian, tôi đã thử giao diện Windows của Mercurial với công cụ tích hợp Hg-Git để tôi có thể sử dụng kho Git của mình và thấy rằng nó dễ sử dụng hơn rất nhiều.

Cảnh báo: Vì bài đăng này tôi đã tìm thấy Mercurial và yêu thích nó hơn SVN rất nhiều. Vì vậy, bài đăng này hơi lỗi thời với các bình luận Pro SVN và chống DVCS nói chung, nhưng các công cụ chống git vẫn có liên quan

Tôi là một fan hâm mộ của SVN trên Git.

Tại sao? Bởi vì SVN dễ dàng hơn nhiều đối với một nhà phát triển hoặc nhóm nhỏ, và git (cụ thể là msysgit) đã để lại cho tôi một mùi vị tồi tệ trong miệng.

Khi tôi đang thực tập tại một cửa hàng nhỏ, tôi đã được giới thiệu về git trên Windows. Tôi ngay lập tức nhận thấy khối lượng công việc cần thiết để khiến nó hoạt động với Github. Đầu tiên, tôi phải tạo khóa riêng ssh, dán khóa công khai vào Github, sau đó mở cuộc thi và mở khóa riêng của tôi mỗi lần tôi muốn ấn, điều này cực kỳ khó chịu.

Và tôi không bao giờ thực sự thích rằng tôi đã kéo xuống toàn bộ kho lưu trữ. Tôi sẽ thừa nhận rằng tôi chưa bao giờ làm việc với bất cứ thứ gì to lớn, nhưng tôi sẽ sợ tải xuống kho lưu trữ của KDE trong Git nếu toàn bộ repo và bản sửa đổi của nó có trên HD của tôi.

Sau đó là quá trình khó hiểu để thực hiện một cam kết. TMK, trước tiên tôi phải "giai đoạn" tất cả các tệp tôi muốn cam kết (đã bị hút khi bạn có nhiều tệp, tôi mất một lúc để tìm lệnh thủ công để xử lý mọi thứ), sau đó thực hiện cam kết, sau đó đẩy vào chính repo (tại sao đó là một hoạt động riêng biệt?!).

Bạn cũng có dữ liệu cam kết không hữu ích (!). Hãy nhìn xem, đây là cam kết 14f74433245ae17aeeaa của cây 2167a4934d0a4a7db0de và cha mẹ d7042abb4821d3faf600. Điều đó có nghĩa là gì? Tôi sẽ có thể tìm ra mọi thứ khá nhanh chóng và không phải tham khảo một số tài liệu kỳ lạ.

Nói về tài liệu, ít nhất là khi tôi đang sử dụng nó, dường như mọi thứ đều ở định dạng tệp linux man, IE khó hiểu và vô dụng với tôi. Tôi hiếm khi có thể tìm thấy nhiều sự giúp đỡ trong các tài liệu và chỉ đơn giản là dùng đến google.

Và với các cam kết, một điều mà tôi không thích là thiếu số phiên bản. Bây giờ tôi biết rằng điều này là do thiết kế của git, nhưng bất kỳ phần mềm nào cũng cần số phiên bản. Tôi vẫn còn nhớ các cam kết đánh dấu sẽ bật lên nói rằng "Phiên bản đã thay đổi thành 1.8.6" hoặc một cái gì đó tương tự, nhưng bạn vẫn không thể tạo số. Đối với tôi, phiên bản là 1.8.6.5164 (phần cuối là số sửa đổi) cho tôi biết nhiều hơn chỉ đơn giản là 1.8.6 và một lưu ý nói rằng một cái gì đó nhỏ đã thay đổi, hãy thử nó

Lấy phần mềm cụ thể, chương trình cơ bản trên Windows là msysgit, một giao diện khủng khiếp. Nó đã khóa tôi vài lần, có giao diện khủng khiếp và tích hợp CLI-GUI là iffy tốt nhất. Những người nghiện dòng lệnh xung quanh tôi thậm chí còn ghét gui hơn.

Bây giờ hãy nhìn vào SVN. Và vì tôi đang ở trên Windows và có tài khoản google, cụ thể là TortoiseSVN và Google Code.

Đầu tiên, tích hợp shell hoàn chỉnh để làm mọi thứ trên kho lưu trữ (và đối với bạn là người linux, RabbitVCS cũng làm điều tương tự), không cần GUI chính. Nhận một kho lưu trữ dễ dàng như một kiểm tra, không cần SSH (không thể nhớ nếu Github yêu cầu SSH cho các lần kéo) và không có toàn bộ repo + tất cả các cam kết trong quá khứ ngồi trên HD của bạn.

Cam kết cực kỳ dễ dàng, chủ yếu là do không yêu cầu SSH hoặc dàn dựng. Bạn chỉ cần kiểm tra tất cả các tệp bạn muốn bằng tùy chọn chọn tất cả rất hữu ích mà trong phiên bản msysgit của tôi không có sẵn, nhập tin nhắn cam kết và nhấn commit. Google Code sau đó hỏi bạn về thông tin đăng nhập của bạn (mà hầu hết khách hàng lưu trữ) và bạn đã hoàn thành. Đơn giản, dễ dàng và không có SSH

Số phiên bản? Với một số mã dễ dàng, bạn có thể thêm số phiên bản và số cam kết vào tất cả các kiểm tra, điều này làm cho mọi việc trở nên dễ dàng hơn nhiều. Bạn cũng có được các số phiên bản có thể sử dụng thực sự cho thấy một sự thay đổi, ví dụ 1.8.6.5165 mới hơn 1.8.6.5164.

Tài liệu? Chà, thật khó để nói Rùa được ghi lại, nhưng tôi thực sự đã không tham khảo tài liệu chính thức trong một thời gian dài mà tôi không thể phán xét. Đọc một hướng dẫn giới thiệu đơn giản là đủ cho tôi.

Sáp nhập là một cái gì đó khác tôi không thể so sánh. Tôi đã phải làm điều đó một lần trong Git khi có người khác cam kết thay đổi tệp tôi đang làm việc, nhưng không bao giờ ở SVN.

Tôi muốn giới thiệu cái nào? Trong các nhóm lớn, git có lợi thế của nó, chủ yếu trong chu kỳ phát triển phi tuyến tính. Trong một dự án khác, tôi thấy 4 lập trình viên bắt đầu trong các nhánh riêng biệt, sau đó hợp nhất tất cả các mã theo những cách rất lạ mà bằng cách nào đó đã biến thành nhánh chính cuối cùng. Github và msysgit đã có một công cụ trực quan thực sự tốt cho toàn bộ dự án mà tôi thực sự thích.

Đối với các nhà phát triển đơn lẻ hoặc các dự án nhóm nhỏ, SVN sẽ là tốt nhất vì hầu hết các tính năng Gits không được sử dụng và bạn chỉ nhận được các phần tiêu cực. Đơn giản là một điều tốt đẹp

Trích dẫn sau đây từ Q4TD khá nhiều tiền cho tôi:

Tôi yêu Git cho đến khi tôi thử nó. Bây giờ tôi yêu Mercurial.

        - Tor Norbye, Podcast Java Posse

Ngoài ra, hssubversion tạo ra một máy khách lật đổ khá tốt cho Linux (nơi tôi thường sử dụng dòng lệnh, không giống như Windows nơi tôi thường sử dụng TortoiseSVN). Ưu điểm lớn nhất: không có .svnthư mục con trong mọi thư mục, chỉ là .hgở cấp cao nhất.

Cập nhật: Đáp lại yêu cầu của Alex trong các bình luận để "nói thêm về lý do tại sao git không hoạt động với bạn và làm thế nào Mercurial hoạt động tốt hơn":

Tôi sẽ không nói rằng Git không hoạt động với tôi, nhưng Murcurial hoạt động tốt hơn IMO.

Tóm lại, đây là Mercurial:

và đây là Git:

Và tôi khẳng định rằng Mercurial sẽ làm mọi thứ mà hầu hết các nhà phát triển sẽ cần nó để làm, mà không cần phải tìm hướng dẫn để tìm ra cách làm những việc hàng ngày.

Phải thừa nhận rằng, thỉnh thoảng tôi chỉ sử dụng Git, nhưng cộng đồng lập trình đã phát cuồng với các ngôn ngữ như Ruby và Python, một phần, vì sự đơn giản và thanh lịch của chúng, trong khi Git cảm thấy như một con lạc đà được thiết kế bởi một ủy ban lạc đà.

Bah, bây giờ hãy nhìn vào những gì bạn đã làm? Có tiếng vang khắp nơi. Di chuyển dọc, không có gì để xem ... không có gì để xem ...

Cập nhật 2: Và một tweet apropos khác tôi vừa gặp:

Phần mềm Git trở nên dễ dàng hơn một khi bạn có được ý tưởng cơ bản rằng các nhánh là các endofunctor nội địa hóa ánh xạ các giao diện con của một không gian Hilbert.

Tôi không có một hệ thống kiểm soát phiên bản "tốt nhất" duy nhất, mà là một mô hình VCS tốt nhất.

Tôi đã sử dụng nhiều hệ thống kiểm soát phiên bản tập trung khác nhau và nhiều hệ thống kiểm soát phiên bản phân tán khác nhau. Và tôi có thể nói mà không do dự rằng không ai nên tự tạo CVCS.

Tôi không quan tâm mà DVCS bạn chọn (đặc biệt yêu thích của tôi là Git), nhưng hãy làm cho mình một đặc ân và sử dụng một DVCS. Đối với một: bạn sẽ linh hoạt hơn nhiều. Các DVCS có thể mô phỏng một cách tầm thường một quy trình công việc CVCS (không bao giờ rẽ nhánh kho lưu trữ và chỉ coi kho lưu trữ cục bộ của bạn như một mánh khóe thay vì một ngã ba độc lập), trong khi điều ngược lại là không thể. Và trong khi về mặt logic, thực hiện mô phỏng này sẽ mang một số chi phí (và thực tế là như vậy), tôi vẫn thấy nó dễ sử dụng hơn (chưa kể hiệu năng cao hơn nhiều do bộ nhớ đệm cục bộ) so với bất kỳ CVCS nào tôi đã sử dụng.

Không thể nói rằng tôi đã gặp phần mềm kiểm soát phiên bản tốt nhất, nhưng tôi có thể bảo bạn tránh xa VSS và MKS. Cả hai đều là những con chó nên tránh bằng mọi giá.

Tôi sẽ không nói điều tốt nhất, nhưng một trong những tính năng và khái niệm rất thú vị.

Fossil là một kiểm soát phiên bản phân tán, theo dõi lỗi và dự án wiki được xây dựng trên cơ sở dữ liệu SQLite làm kho lưu trữ.

Nhóm máy chủ nền tảng

Bởi vì:

1. Đó là một VCS tốt, vững chắc . (Tôi sẽ không coi nó là tốt nhất bằng mọi cách, nhưng nó có những tính năng bổ sung tuyệt vời.)
2. Tính năng theo dõi nhiệm vụ và theo dõi tích hợp của nó được tích hợp vào Visual Studio giúp tôi tập trung và biết tôi cần làm gì ở một nơi (tự động áp dụng đăng ký vào lỗi hoặc tác vụ và đóng nó khá tốt, mặc dù bạn có thể nhận plugin cho các hệ thống khác / nhật thực / vv để làm điều này.)
3. Nó tích hợp các tác vụ / theo dõi lỗi / dự án trực tiếp vào Project Server, vì vậy tôi hiếm khi phải giữ các kế hoạch dự án hoặc bảng chấm công cập nhật. Các bản cập nhật cho Project trong Project Server sẽ tự động lọc xuống dưới dạng các tác vụ vào TFS và vào Visual Studio để tôi tự động xem.

Tôi đã sử dụng vô số hệ thống kiểm soát phiên bản trong lịch sử lâu dài của mình:

• RPPT - (Cuộn băng giấy đục lỗ). Trong một hộp giày. Tôi không đùa.
• PVCS - (Hệ thống kiểm soát phiên bản Polytron). Các VCS thực sự đầu tiên tôi sử dụng.
• SCCS - rất lâu trước đây, tôi không nhớ bất kỳ điều gì đặc biệt tốt hay xấu về nó.
• RCS - như những người khác đã chỉ ra, thà hút những quả bóng lừa ướt đẫm mồ hôi.
• CVS - đó chỉ là một nỗi đau khi được sử dụng với hơn 2 lập trình viên. tính năng tốt nhất: rcs2cvs.
• VSS - nó hoạt động, ngoại trừ vào thứ ba, khi nó làm hỏng toàn bộ kho lưu trữ của bạn.
• Perforce - chi phí nhiều hơn xe của tôi. Bản thân VCS có thể chấp nhận được, nhưng những kẻ IT tinh ranh kiểm soát mọi khía cạnh của việc sử dụng nó sẽ không bao giờ đưa nó vào danh sách "ưa thích" của tôi.
• SVN - phân nhánh và sáp nhập là một con chó cái, nhưng nói chung nó tốt hơn bất kỳ cái nào trước đây. Không tốt lắm với rất nhiều thay đổi nhỏ đang chờ xem xét.
• Mercurial - những gì tôi có ít kinh nghiệm với nó, tôi thích. Tôi có thể thử nó trong dự án tiếp theo của tôi.
• Git - không bao giờ có cơ hội sử dụng nó.

Mặc dù một cặp vợ chồng là khủng khiếp, hầu hết là "tốt". Họ không cản đường tôi. Miễn là một công cụ không làm cho cuộc sống của tôi khó khăn hơn đáng kể , tôi không thực sự bận tâm.

Điều thực sự là để hiểu được điểm mạnh và điểm yếu của từng. Hiểu môi trường mục tiêu:

• phân phối hoặc địa phương
• đội nhỏ hay lớn
• dịch vụ lưu trữ vcs hay không
• tích hợp dễ dàng vào các công cụ khác

Joel cũng đưa ra một quan sát quan trọng: Tìm hiểu công cụ và mô hình sử dụng thực sự của nó. Anh ta cố gắng hết sức để làm cho Mercurial hành xử như Subversion.

Một hệ thống mới hơn mà chúng tôi sử dụng tại văn phòng của tôi là Nhựa SCM (http://www.platicscm.com/). Nó hoạt động rất tốt cho nhóm nhỏ của chúng tôi và cho chúng tôi một số quyền kiểm soát tuyệt vời đối với mọi khía cạnh của quản lý nguồn.

SCCS .

Hoặc, nếu bạn không sống trong hang động trong 38 năm qua, CSSC .

Nghiêm túc mà nói, công ty của tôi đang sử dụng TeamWare , một loại DVCS giả dựa trên SCCS.

Không, tôi không đùa.

Sun đã chuyển sang đồng bóng từ TeamWare chỉ một vài năm trước đây. Bây giờ bạn nên hiểu tại sao Java dường như di chuyển chậm như vậy.

MPW: Chà, tôi thực sự không thể đánh giá nó bất chấp những nỗ lực của tôi.

Điều này đã trở lại khi tôi đang học lập trình ở trường trung học, và trình biên dịch C ++ thực sự miễn phí duy nhất có được là Macintosh Lập trình Workbench, mà tôi đã giữ trên một đĩa zip và bật vào bất cứ nơi nào Performancea có sẵn trong phòng thí nghiệm.

MPW đi kèm với hàng tá công cụ (không có công cụ nào là resedit, đó là một bản tải xuống riêng) và một trong số đó là tiện ích kiểm soát phiên bản. Nó xuất hiện mở một cửa sổ nhỏ với một dòng văn bản và bạn phải kéo và thả các dự án hoặc tệp của mình vào đó. Nó không có tài liệu mà tôi từng có thể khám phá, bất thường khi xem xét mọi thứ khác dường như có tài liệu tuyệt vời, và vì vậy tôi chưa bao giờ tìm ra cách sử dụng nó.

Đó là bàn chải đầu tiên của tôi với VC, và là cái cuối cùng trong một thời gian dài. Bây giờ tôi sử dụng git cho tất cả mọi thứ.

RCS - Hệ thống kiểm soát sửa đổi

Mã hóa Solo được thực hiện rất dễ dàng.

Không phải ClearCase, ít nhất là đối với hệ thống Unix / Linux (có lẽ với Windows, trình cài đặt dễ dàng hơn). Tôi đã dễ dàng hơn để tìm hiểu một công cụ mới, Perforce, thay vì nâng cấp máy chủ ClearCase của chúng tôi.

Tôi hiện đang sử dụng Perforce trong công việc và tôi thích nó nhưng tôi không biết nó có phải là tốt nhất không. Thiết lập môi trường dòng lệnh và Máy chủ Perforce hơi khó xử, nhưng sử dụng Visual Client khá dễ dàng. Tôi thích nghĩ rằng người dùng có một thời gian khá dễ dàng với nó cho các công việc hàng ngày; nó chỉ là thiết lập ban đầu mất một số công việc.

Tôi đã sử dụng Visual SourceSafe và ghét nó, nhưng nó tốt hơn không có gì, nhưng không nhiều. Trong vài năm qua, đã sử dụng một thứ gọi là QCVS do Qumasoft.com viết, sở hữu và hỗ trợ bởi lập trình viên Jim Voris. Gui đơn giản, giá rẻ, hỗ trợ tốt.

Chỉ cần làm công việc.