SVN làm gì tốt hơn Git? [đóng cửa]

Không có câu hỏi rằng phần lớn các cuộc tranh luận về các công cụ lập trình chắt lọc theo lựa chọn cá nhân (bởi người dùng) hoặc nhấn mạnh thiết kế , nghĩa là tối ưu hóa thiết kế theo các trường hợp sử dụng cụ thể (bởi người xây dựng công cụ). Trình chỉnh sửa văn bản có lẽ là ví dụ nổi bật nhất - một lập trình viên làm việc trên Windows tại nơi làm việc và mã trong Haskell trên máy Mac ở nhà, giá trị tích hợp đa nền tảng và trình biên dịch và do đó chọn Emacs trên TextMate , v.v.

Điều ít phổ biến hơn là một công nghệ mới được giới thiệu thực sự, vượt trội hơn hẳn so với các tùy chọn còn tồn tại.

Trên thực tế, đây có phải là trường hợp với các hệ thống kiểm soát phiên bản (VCS), đặc biệt là VCS tập trung ( CVS và SVN ) so với VCS phân tán ( Git và Mercurial ) không?

Tôi đã sử dụng SVN trong khoảng năm năm và SVN hiện đang được sử dụng tại nơi tôi làm việc. Ít hơn ba năm trước, tôi đã chuyển sang Git (và GitHub) cho tất cả các dự án cá nhân của tôi.

Tôi có thể nghĩ về một số lợi thế của Git so với Subversion (và phần lớn là trừu tượng đối với các lợi thế của phân phối trên VCS tập trung), nhưng tôi không thể nghĩ ra một ví dụ đối lập - một số nhiệm vụ (có liên quan và phát sinh trong một lập trình viên thông thường quy trình làm việc) mà Subversion làm tốt hơn Git.

Các chỉ kết luận tôi đã rút ra từ này là tôi không có bất kỳ dữ liệu - không phải là Git là tốt hơn, vv

Tôi đoán là những ví dụ phản biện như vậy tồn tại, do đó câu hỏi này.

Subversion là một kho lưu trữ trung tâm

Trong khi nhiều người sẽ muốn có các kho lưu trữ phân tán vì lợi ích rõ ràng của tốc độ và nhiều bản sao, có những tình huống mà một kho lưu trữ trung tâm là mong muốn hơn. Ví dụ: nếu bạn đã có một số đoạn mã quan trọng mà bạn không muốn ai truy cập, có lẽ bạn không muốn đặt nó dưới Git. Nhiều tập đoàn muốn giữ mã của họ tập trung, và (tôi đoán) tất cả các dự án chính phủ (nghiêm túc) đều nằm trong kho trung tâm.

Lật đổ là khôn ngoan thông thường

Điều này có nghĩa là nhiều người (đặc biệt là người quản lý và ông chủ) có cách thông thường để đánh số các phiên bản và xem sự phát triển là một "dòng duy nhất" theo thời gian được mã hóa vào não của họ. Không xúc phạm, nhưng sự tự do của Git không dễ nuốt. Chương đầu tiên của bất kỳ cuốn sách Git nào sẽ cho bạn xóa hết tất cả những lý tưởng thông thường khỏi tâm trí của bạn và bắt đầu lại.

Subversion làm điều đó một cách, và không có gì khác

SVN là một hệ thống kiểm soát phiên bản. Nó có một cách để thực hiện công việc của mình và mọi người đều làm theo cách tương tự. Giai đoạn = Stage. Điều này giúp dễ dàng chuyển đổi sang / từ SVN từ / sang các VCS tập trung khác. Git thậm chí KHÔNG phải là một VCS thuần túy - đó là một hệ thống tệp, có nhiều cấu trúc liên kết về cách thiết lập kho lưu trữ trong các tình huống khác nhau - và không có bất kỳ tiêu chuẩn nào. Điều đó làm cho nó khó khăn hơn để chọn một.

Các ưu điểm khác là:

• SVN hỗ trợ các thư mục trống
• SVN có hỗ trợ Windows tốt hơn
• SVN có thể kiểm tra / sao chép một cây con
• SVN hỗ trợ kiểm soát truy cập độc quyền svn lock, hữu ích cho các tệp khó hợp nhất
• SVN hỗ trợ các tệp nhị phân và các tệp lớn dễ dàng hơn (và không yêu cầu sao chép các phiên bản cũ ở mọi nơi).
• Thêm một cam kết bao gồm ít bước hơn đáng kể vì không có bất kỳ lực kéo / đẩy nào và những thay đổi cục bộ của bạn luôn được phản hồi ngầm svn update.

Một lợi ích của Subversion so với Git có thể là Subversion chỉ cho phép kiểm tra các cây con. Với Git, toàn bộ kho lưu trữ là một đơn vị, bạn chỉ có thể nhận được tất cả hoặc không có gì. Với mã mô-đun, điều này có thể khá đẹp so với các mô đun con Git. (Trong khi các mô đun con Git cũng có vị trí của chúng, rõ ràng.)

Và một lợi ích nhỏ bé: Subversion có thể theo dõi các thư mục trống. Git theo dõi nội dung tệp, vì vậy một thư mục không có tệp nào sẽ không hiển thị.

Tôi có thể nghĩ về ba. Đầu tiên, nó khá dễ dàng hơn để tìm kiếm, đặc biệt là đối với những người không phát triển. Về mặt khái niệm, nó đơn giản hơn nhiều so với các tùy chọn DCVS . Thứ hai là sự trưởng thành, đặc biệt là TortoiseSVN trên Windows. RùaHg đang bắt kịp nhanh chóng. Thứ ba, bản chất của quái thú - chỉ là hình ảnh của một hệ thống tệp mà bạn có thể kiểm tra mọi thứ từ bất kỳ cấp độ nào của cây - có thể rất hữu ích trong một số trường hợp - như phiên bản nhiều tệp cấu hình khác nhau rộng rãi trên hàng tá của các máy chủ không có hàng tá kho lưu trữ.

Điều này không có nghĩa là chúng ta sẽ không chuyển tất cả sự phát triển sang Mercurial.

• Các kho lưu trữ SVN dễ quản lý hơn theo quan điểm của người quản lý và quản trị viên ( ACL + phương thức xác thực + hotcopy + gương + bãi)
• SVN * -hooks dễ thực hiện và hỗ trợ hơn
• svn:external có sức mạnh và tính linh hoạt hơn mô hình con
• Các cây kho lưu trữ dựa trên hệ thống tệp dễ sử dụng hơn các kho lưu trữ nguyên khối với sự phân tách chỉ logic
• SVN có nhiều công cụ khách hàng khác nhau
• SVN có các trang web có thể sử dụng của bên thứ ba, tốt hơn nhiều so với Git
• SVN không phá vỡ não của bạn

Tôi đã viết bài này như một bình luận về câu trả lời của người khác, nhưng tôi đoán nó xứng đáng là một câu trả lời.

Cấu hình được chọn cẩn thận của công ty tôi cho SVN yêu cầu khóa cấp độ tệp để chỉnh sửa nội dung và không bao giờ sử dụng hợp nhất. Kết quả là, nhiều nhà phát triển tranh nhau về các khóa và nó có thể là một nút cổ chai lớn và không bao giờ có bất kỳ cơ hội nào cho một cuộc xung đột hợp nhất.

SVN chắc chắn kiểm soát quản lý từ trên xuống tốt hơn Git. Trong quá trình di chuyển skunkworks của tôi đến Git (yêu cầu sự tha thứ thay vì sự cho phép) tôi đã nhiều lần làm người quản lý của mình khiếp sợ với khái niệm rằng không có bất kỳ máy chủ điều khiển trung tâm nào được thi hành bằng phần mềm mà chúng ta đều là nô lệ.

Lý do của tôi:

• trưởng thành - cả máy chủ và công cụ (ví dụ: TortoiseSVN)
• đơn giản - ít bước liên quan, một cam kết là một cam kết. DVCS như Git và Mercurial liên quan đến cam kết, sau đó đẩy.
• xử lý nhị phân - SVN xử lý các tệp thực thi nhị phân và hình ảnh tốt hơn Git / Hg. Đặc biệt hữu ích với các dự án .NET vì tôi muốn kiểm tra các công cụ liên quan đến xây dựng vào kiểm soát nguồn.
• đánh số - SVN có sơ đồ đánh số cam kết dễ đọc, chỉ sử dụng các chữ số - dễ dàng hơn để theo dõi các số sửa đổi. Git và Hg làm điều này khá khác nhau.

Tôi đánh giá cao rằng bạn đang tìm kiếm thông tin tốt, nhưng loại câu hỏi này chỉ mời, "Tôi nghĩ Git là rất nhiều chiến thắng, và svn teh suxorz!" câu trả lời.

Tôi đã cố gắng và cá nhân tôi thấy Git hơi quá nhiều cho đội nhỏ của mình. Có vẻ như nó sẽ là tuyệt vời cho một nhóm phân phối lớn hoặc một nhóm các đội được phân tán theo địa lý. Tôi hiểu rất nhiều lợi ích của Git, nhưng theo tôi, kiểm soát nguồn không phải là thứ khiến tôi thức đêm.

Tôi là một thợ săn hươu, và khi tôi và bạn bè của tôi đi ra ngoài, họ được trang bị tới tận răng, được trang bị đạn và thiết bị công nghệ cao. Tôi xuất hiện với một khẩu súng trường, bảy viên đạn và một con dao găm. Nếu tôi cần nhiều hơn bảy vòng thì tôi đang làm gì đó sai, và tôi cũng làm như bất kỳ ai khác.

Điểm tôi đang cố gắng đưa ra là nếu bạn là một nhóm nhỏ làm việc trong một dự án vừa và nhỏ và bạn đã quen thuộc với SVN thì hãy sử dụng nó. Nó chắc chắn tốt hơn CVS hoặc (shudder) SourceSafe và tôi không mất hơn năm phút để thiết lập kho lưu trữ. Git đôi khi có thể là quá mức cần thiết.

Đây là tất cả tương đối, và như maple_shaft đã nói, nếu một cái phù hợp với bạn, đừng thay đổi!

Nhưng nếu bạn thực sự muốn một cái gì đó , tôi muốn nói rằng nó có thể tốt hơn cho các nhà thiết kế, lập trình viên web và như vậy - nó xử lý hình ảnh và tệp nhị phân tốt hơn một chút.

Tính khả dụng. Nó không thực sự khen Subversion nhưng thay vì TortoiseSVN 's .. TortoiseGit tồn tại, nhưng nó vẫn có một chặng đường dài để đi để phù hợp với TortoiseSVN.

Nếu bạn hỏi Git làm gì tốt hơn SVN, tôi sẽ trả lời GitHub . Thật buồn cười khi các công cụ của bên thứ ba tạo ra sự khác biệt lớn như vậy.

Khi bạn không cần phân nhánh và hợp nhất , SVN (với TortoiseSVN trên Windows) rất dễ hiểu và dễ sử dụng. Git quá phức tạp đối với các trường hợp đơn giản, vì nó cố gắng làm cho việc phân nhánh / hợp nhất trở nên dễ dàng.

(Rất nhiều dự án nhỏ không bao giờ phải phân nhánh nếu chúng được quản lý tốt. Git nhắm vào các trường hợp phức tạp; do đó, hầu hết các tài liệu Git đều cho rằng bạn cần thực hiện các hoạt động phức tạp như phân nhánh và sáp nhập.)

Chà, ông tôi có thể sử dụng SVN trên máy tính Windows XP của mình, nhưng ông gặp khó khăn khi sử dụng Git. Có lẽ đây là một thành tựu của TortoiseSVN so với TortoiseGit , nhưng tôi nghĩ nó khá gắn liền với thực tế, rằng Git vốn đã mạnh hơn và do đó phức tạp hơn, và sẽ vô nghĩa khi hạ thấp nó xuống cùng cấp độ.

Bây giờ nó không thực sự quan trọng đối với ông tôi, vì ông đã không thực hiện bất kỳ chương trình nào vào cuối. Tuy nhiên, tôi đã từng ở trong một đội, nơi các nghệ sĩ đồ họa của chúng tôi cũng đang sử dụng kiểm soát nguồn của chúng tôi.

Và đó là những người chỉ đơn giản mong đợi các công cụ của họ hoạt động (tôi cũng vậy, nhưng tôi có cơ hội thực tế để khiến họ làm việc trong trường hợp thất bại) và trực quan. Ngoài thực tế, rằng sẽ rất nỗ lực để khiến họ hòa hợp với DVCS , có rất ít để đạt được. Và chỉ với hai lập trình viên trong đội, chúng tôi cũng cảm thấy hợp lý với SVN.

Tại nơi làm việc, tôi không thể chuyển các nhà phát triển từ SVN sang bất kỳ DVCS nào vì hai lý do:

• Kiểm tra một phần (giống như chỉ có ba thư mục từ các độ sâu khác nhau trong cây dự án)
• Khóa tệp (báo cáo định dạng nhị phân)

• Cảm giác an toàn khi thực hiện một 'svn commit'. Vì các cam kết đi đến máy chủ, không có khả năng tôi có thể làm điều đó sẽ xóa các thay đổi của mình sau khi chúng được cam kết. Trong git, các cam kết là cục bộ, vì vậy cho đến khi tôi đẩy, một 'rm -rf' đi lạc và tất cả đã kết thúc.
• Cam kết được chứng thực. Theo mặc định trong git tôi có thể nói rằng tôi đang cam kết như bất kỳ ai.
• Ít lệnh hơn để học để sử dụng hàng ngày. 'svn checkout', 'svn up' và 'svn commit' sẽ giúp bạn đi khá xa.
• Kiểm tra chia sẻ làm việc tốt hơn rất nhiều. Khi bạn đi đến cam kết, nó sẽ hỏi bạn tên người dùng / mật khẩu của bạn, bạn không cần phải nhớ để vượt qua các đối số dòng lệnh nhất định. Đôi khi tại nơi làm việc, chúng tôi có một máy dùng chung với thanh toán svn được chia sẻ của một số dự án. Ai đó có thể nói "Bob bạn có thể xem cái này trên máy này" và anh ta có thể, và anh ta có thể cam kết thay đổi của mình với tư cách là người dùng của mình mà không cần bất kỳ sự cố nào.
• Bố trí kho lưu trữ. Bạn có thể có một dự án ô và các tiểu dự án và chọn những gì cần kiểm tra khi nào.
• Số sửa đổi là số nguyên tăng dần.
• Được thiết kế cho quy trình lưu trữ trung tâm.

Những người khác đã đăng một số câu trả lời khá tốt, nhưng về Quyền thì sao? Sử dụng Subversion qua SSH, bạn có thể tạo một tài khoản riêng trên máy chủ của mình cho SVN. Các nhà phát triển khác nhau có thể được cấp quyền truy cập khác nhau vào các phần khác nhau của kho lưu trữ. GIT có thể làm điều đó? Tôi đoán là có gitolite, nhưng nó dường như không linh hoạt hoặc mạnh mẽ đối với tôi, tôi cũng không biết ai đang thực sự sử dụng nó.

Tốc độ. Đôi khi mất 10 hoặc 15 phút để sao chép một kho lưu trữ git lớn, trong khi kho lưu trữ lật đổ có kích thước tương tự phải mất vài phút để kiểm tra.

Tôi đăng bài này như một phản hồi chứ không phải là một bình luận.

Tôi thừa nhận rằng DVCS đang khá thịnh hành, nhưng tôi sẽ cố gắng giải thích tại sao.

DVCS tốt hơn bởi vì giống như nhiều người đã nói, "đây là cách chúng ta nên làm việc lại từ đầu". Đó là sự thật, bạn có thể làm với DVCS những gì bạn đã sử dụng với SVN, vì vậy theo cách khiến SVN trở nên lỗi thời.

Tuy nhiên, không phải mọi dự án phần mềm đều tốt như nó có được:

• Dự án dài hạn được hưởng lợi rất nhiều từ DVCS, vì nó sử dụng ít chi phí hơn, cho phép quản lý tốt hơn (phân nhánh, v.v.) và được hỗ trợ rất nhiều bởi các máy chủ như mã google và github.

• Những dự án đó không phải là những dự án duy nhất, có những loại dự án khác đang được phát triển trong các công ty mà không có bất kỳ sự trợ giúp nào từ thế giới bên ngoài hoặc internet: mọi thứ đều được thực hiện trong nội bộ và thường trong thời gian ngắn. Một ví dụ điển hình: một trò chơi video. Mã phát triển nhanh chóng.

Đối với trường hợp sau, các nhà phát triển không thực sự cần các tính năng phân nhánh hoặc tinh vi mà DVCS có thể cung cấp, họ chỉ muốn chia sẻ mã nguồn và tài sản. Mã họ tạo ra không có khả năng được sử dụng lại, vì có thời hạn. Họ dựa vào SVN chứ không phải DVCS vì một số lý do:

• Các nhà phát triển có máy móc thuộc về công ty và điều này có thể thay đổi nhanh chóng. Cấu hình một repo là mất thời gian.
• Nếu những kẻ đó không có máy riêng, họ sẽ ít làm việc trên cùng một mã nguồn / một phần của dự án. Cộng với một cho dữ liệu tập trung.
• tốc độ mạng và số tiền lớn cho phép sử dụng một máy chủ tập trung xử lý mọi thứ SVN, đó là thông lệ xấu nhưng sao lưu được thực hiện, v.v.
• SVN chỉ đơn giản để sử dụng, ngay cả khi đó là cách sai: đồng bộ hóa các tệp trên các thiết bị ngang hàng không phải là vấn đề đơn giản và "thực hiện đúng cách" chỉ không thể thực hiện kịp thời nếu bạn luôn muốn nó hoàn hảo.

Hãy nghĩ về cỗ máy công nghiệp trò chơi và cách SVN tiết kiệm thời gian; mọi người giao tiếp nhiều hơn với các dự án đó bởi vì các trò chơi là về lập trình lặp đi lặp lại và mã thích ứng: không có gì khó để viết mã, nhưng nó phải được thực hiện đúng cách, càng sớm càng tốt. Các lập trình viên được thuê, họ mã hóa phần của họ, biên dịch nó, kiểm tra nó một chút, cam kết, thực hiện, người kiểm thử trò chơi sẽ giải quyết phần còn lại.

DVCS được tạo ra cho internet và cho dự án rất phức tạp. SVN dành cho các dự án nhóm nhỏ, ngắn hạn, chặt chẽ. Bạn không cần phải học hỏi nhiều từ SVN, đó gần như là một FTP với sự khác biệt ngu ngốc.

Subversion và Git đều khuyến khích các cách tiếp cận cụ thể (và rất khác nhau) để phát triển và hợp tác. Một số tổ chức sẽ nhận được nhiều hơn từ Git và những tổ chức khác sẽ nhận được nhiều hơn từ Subversion, tùy thuộc vào tổ chức và văn hóa của họ.

Git và Mercurial đều tuyệt vời cho các nhóm phân phối và tổ chức lỏng lẻo của các lập trình viên chuyên nghiệp có thẩm quyền cao. Cả hai công cụ DVCS phổ biến này đều khuyến khích các kho lưu trữ nhỏ, với việc sử dụng lại giữa các nhà phát triển diễn ra thông qua các thư viện được xuất bản với giao diện (tương đối) ổn định.

Subversion, mặt khác, khuyến khích một cấu trúc quản lý kết hợp chặt chẽ và tập trung hơn, với nhiều giao tiếp hơn giữa các nhà phát triển và mức độ kiểm soát tổ chức lớn hơn đối với các hoạt động phát triển hàng ngày. Trong các nhóm được tổ chức nhỏ gọn hơn này, việc sử dụng lại giữa các nhà phát triển có xu hướng diễn ra thông qua các thư viện chưa được công bố với giao diện (tương đối) không ổn định. TortoiseSVN cũng cho phép Subversion hỗ trợ các nhóm đa ngành với các thành viên không phải là lập trình viên chuyên nghiệp (ví dụ: kỹ sư hệ thống, kỹ sư thuật toán hoặc chuyên gia trong lĩnh vực chủ đề khác).

Nếu nhóm của bạn được phân phối, với các thành viên làm việc tại nhà hoặc từ nhiều trang web quốc tế khác nhau hoặc nếu họ thích làm việc một mình và im lặng, ít giao tiếp mặt đối mặt, thì một DVCS như Git hoặc Mercurial sẽ tốt phù hợp văn hóa.

Mặt khác, nếu nhóm của bạn nằm trên một trang web duy nhất, với cách tiếp cận "nhóm" tích cực để phát triển và nhiều giao tiếp trực tiếp, với "tiếng vang" trong không khí, thì SVN có thể là một phù hợp văn hóa tốt hơn, đặc biệt nếu bạn có nhiều đội ngũ kỷ luật chéo.

Tất nhiên, có thể cấu hình Git và Hg (mạnh mẽ và linh hoạt như họ) để làm bất cứ điều gì bạn muốn, nhưng nó chắc chắn là công việc nhiều hơn và chúng chắc chắn khó sử dụng hơn, đặc biệt là đối với những thành viên trong nhóm tự nhiên sẽ không có xu hướng sử dụng bất kỳ hình thức kiểm soát phiên bản nào.

Cuối cùng, tôi cũng thấy rằng chức năng chia sẻ bằng cách sử dụng phát triển thư viện "nóng" theo Svn (với CI và cách tiếp cận dựa trên thử nghiệm) cho phép tốc độ phát triển phối hợp khó đạt được với một nhóm phân phối và kết nối lỏng lẻo hơn.

Dưới đây là hai lý do mà tôi vẫn ở lại với SVN.

1. Các đường cong học tập. SVN dễ dàng hơn Git, thậm chí cả thiết lập (máy chủ hoặc máy khách cũng vậy), khả năng sử dụng và các lệnh.
2. Các gói máy chủ tốt hơn như Subversion Edge , VisualSVN , uberSVN , v.v.

Có hai xu hướng chính trong kiểm soát phiên bản ngay bây giờ; Phân phối và tích hợp .

Git là tuyệt vời ở phân cấp.

SVN có rất nhiều công cụ được xây dựng tích hợp với nó. Việc cài đặt máy chủ SVN của bạn là phổ biến để khi bạn kiểm tra sửa lỗi, bạn đề cập đến số lỗi trong nhận xét đăng ký và nó sẽ tự động đặt trạng thái "đang kiểm tra" và thông báo cho người kiểm tra được chỉ định rằng họ cần phải nhìn nó. Sau đó, bạn có thể gắn thẻ một bản phát hành và nhận danh sách tất cả các lỗi đã được sửa trong bản phát hành này.

Các công cụ làm điều này với SVN đã hoàn thiện và được sử dụng hàng ngày.

Trong Subversion, bạn có thể chỉnh sửa thông điệp tường trình (còn được gọi là "thông điệp cam kết") sau khi cam kết được thực hiện và đẩy. Đối với hầu hết các ứng dụng thực tế, điều này là không thể bởi thiết kế trong các hệ thống phi tập trung, bao gồm cả git. Tất nhiên, trong git bạn có thể thực hiện "git commit --amend", nhưng điều đó không giúp ích gì cho bạn sau khi cam kết của bạn bị đẩy đi nơi khác. Trong SVN, khi bạn chỉnh sửa thông điệp tường trình, bạn đang thực hiện nó trên kho lưu trữ trung tâm mà mọi người chia sẻ, vì vậy mọi người sẽ nhận được chỉnh sửa và không thay đổi số nhận dạng của bản sửa đổi.

Chỉnh sửa thông điệp tường trình sau khi thực tế thường rất hữu ích. Ngoài việc chỉ sửa một lỗi hoặc thiếu sót trong thông điệp tường trình, nó còn cho phép bạn thực hiện những việc như cập nhật thông điệp tường trình để tham khảo một cam kết trong tương lai (chẳng hạn như sửa đổi sửa lỗi hoặc hoàn thành công việc được giới thiệu trong phiên bản hiện tại) .

Nhân tiện, không cần phải mất thông tin. Các móc nối thay đổi trước và thay đổi sau đổi mới có thể lưu lại lịch sử của các tin nhắn cũ nếu bạn thực sự quan tâm hoặc gửi email với thông điệp nhật ký khác (thực tế là phổ biến hơn), do đó, có một đường mòn kiểm toán.