Lý do cụ thể cho việc vẫn sử dụng Subversion? [đóng cửa]

22

Tôi muốn chọn một hệ thống kiểm soát phiên bản cho công ty của tôi. Cho đến nay tôi biết tôi có Git, Subversion và Mercurial.

Ngày nay tôi thấy rằng Git được sử dụng nhiều nhất, vì vậy tôi tự hỏi: liệu có lý do cụ thể nào để vẫn sử dụng Subversion hay tôi nên trực tiếp đến Git?

version-control  git  svn 
— người dùng1179459
nguồn
36
Cả hai đều làm việc. Điều quan trọng là liệu họ có đáp ứng yêu cầu của bạn không, điều mà bạn chưa nói với chúng tôi.
— Matthew Flynn
6
— ghê tởm
11
Bạn loại trừ Mercurial trên đối số nào?
— mouviciel
8
-1 cho cách diễn đạt chủ quan (đánh lừa IMHO) và "Những ngày đó tôi thấy rằng Git được sử dụng nhiều nhất" - cần dẫn nguồn. Git cực kỳ phổ biến trong thế giới nguồn mở, nhưng trong không gian của công ty, nó hiếm hơn nhiều . Quân đoàn thực sự thích ý tưởng về một kho lưu trữ duy nhất, trung tâm, có thẩm quyền và rất chậm thay đổi. Trong không gian công ty, bạn có nhiều khả năng nhìn thấy CVS tốt hơn SVN, thậm chí không bao giờ bận tâm đến DVCS.
— Keith
4
@RobinWinslow - SVN khác với Git. Phù hợp hơn với một số trường hợp và phù hợp hơn với những người khác. Cá nhân tôi thích DVCS nói chung và bạn rõ ràng thích Git, nhưng cả hai đều là ý kiến ​​chủ quan. Chúng không phải không có giá trị, nhưng chúng không thuộc về một trang web như thế này.
— Keith

Câu trả lời:

46

SVN hoàn toàn không chết. Nó vẫn đang được sử dụng rất rộng rãi và nó sẽ không đi đâu cả sớm. SVN sử dụng đơn giản hơn nhiều so với kiểm soát phiên bản phân tán, đặc biệt nếu bạn không thực sự chạy một dự án phân tán cần kiểm soát phiên bản phân tán.

Nếu bạn chỉ có một kho lưu trữ trung tâm (đó là tất cả công ty của bạn sẽ cần nếu chúng vẫn đủ nhỏ để có được mà không cần kiểm soát nguồn cho đến nay), việc sử dụng SVN để tương tác với nó sẽ đơn giản hơn nhiều. Ví dụ: với SVN, bạn có thể lấy các thay đổi từ kho lưu trữ hoặc cam kết các thay đổi cục bộ của mình với nó, chỉ với một thao tác, trong khi HG và Git yêu cầu hai hoặc ba bước để thực hiện công việc tương đương.

Và với những sửa đổi gần đây, SVN đã khắc phục rất nhiều vấn đề về hiệu năng khiến mọi người thích HG và Git. Bây giờ nó nhanh hơn đáng kể so với vài năm trước và tại thời điểm này, thực sự không có lý do chính đáng nào để xem xét HG hoặc Git cho dự án của bạn trừ khi bạn thực sự cần các tính năng nâng cao của kiểm soát phiên bản phân tán.

— Bánh xe Mason
nguồn
16
Tôi hoàn toàn không đồng ý với ước tính của bạn, nhưng tôi muốn thêm một điểm quan trọng có lợi cho SVN: Nhiều người trong ngành thoải mái với SVN nhưng không biết đủ Git để làm việc thoải mái với nó. Nếu toàn bộ nhóm của bạn đã quen với SVN, thì việc chuyển sang Git có thể sẽ có chi phí khá cao. (Tất nhiên điều ngược lại cũng có thể đúng).
— Joachim Sauer
8
Tôi sẽ nâng cao hàng chục lần nếu tôi có thể. Nhiều người đi theo mốt, nhưng không thực sự nghĩ tại sao họ cần kiểm soát nguồn phân tán.
— Euphoric
21
@Euphoric: Tôi biết chính xác lý do tại sao tôi luôn muốn kiểm soát nguồn phân tán trên mỗi dự án. Nó có tác dụng phụ quan trọng của việc phân nhánh và hợp nhất đơn giản, rõ ràng và đáng tin cậy. Subversion vẫn bị sa lầy trong các trường hợp góc với phân nhánh vì mô hình cơ bản mà nó chọn đơn giản làm cho nó phức tạp hơn.
— Jan Hudec
18
Kiểm soát phiên bản phân tán không phải là "mốt". Đây là một sự phát triển của kiểm soát nguồn, giống như kiểm soát phiên bản đồng thời là một sự tiến hóa trong mô hình khóa tệp.
— JesperE
6
@MichaelBorgwardt, tôi thực sự đã làm điều đó một số lần. Nó dễ dàng hơn nhiều so với lật đổ, thực tế là mọi thứ đều cục bộ giúp ích rất nhiều, không cần phải giải thích sự tương tác giữa "máy khách" và "máy chủ". Quy trình làm việc trong git hoặc hg tự nhiên và trực quan hơn nhiều (nếu bạn tránh xa các bit phức tạp như chỉnh sửa lịch sử).
— SK-logic
19

Dụng cụ khách hàng chưa được đề cập. Bạn chắc chắn có thể làm mọi thứ với một tập lệnh dòng lệnh nhưng có tích hợp GUI có thể là một sự tăng năng suất thực sự.

Chúng tôi làm việc chủ yếu với Visual Studio; tích hợp vào IDE chắc chắn tốt hơn với SVN so với Git ngay bây giờ. Điều này có thể thay đổi trong tương lai, nhưng tôi chắc chắn cân nhắc điều này vào quyết định của bạn cũng giống như các chức năng kiểm soát phiên bản.

Cũng giống như mọi thứ khác, bản thân hệ thống kiểm soát phiên bản không phải là mục tiêu, chỉ là một công cụ giúp bạn đến nơi bạn đến. Chọn một trong đó sẽ đưa bạn đến đó nhanh nhất dựa trên tình huống của bạn.

— số 101
nguồn
Đây là điểm tốt. Tôi nghĩ một trong những lý do khiến mọi người thích Git hơn SVN là Git có công cụ CLI tốt hơn. Nhưng điều này có thể được bù đắp bằng GUI SVN của bên thứ 3 tốt, như TortoiseSVN trên Windows.
— Euphoric
2
Đây là một trong những lý do chúng tôi đã đi vì Mercurial (và TortoiseHg) trên Git. Những lợi thế của kiểm soát phiên bản phân tán và công cụ tốt và tích hợp IDE.
— HappyCat
15

Tôi là một người hâm mộ Git. Gần đây tôi đã phải thừa nhận rằng một trong những nhược điểm của Git là nó xác định các phiên bản có giá trị băm ngược với số phát hành của svn. Số phát hành có thể dễ dàng chuyển qua điện thoại hoặc đại loại như thế.

Và đó là pro duy nhất tôi có thể tưởng tượng. Nếu bạn thực sự muốn dựa vào tính năng đó, bạn có thể có nó trong một VCS Bazaar phân tán và / hoặc tập trung . Trong Git có các thẻ có thể phục vụ mục đích.

Dù sao, tôi chỉ không thể tưởng tượng được việc phát triển mà không cần chuyển đổi chi nhánh nhanh chóng và đâm vào. Hai tính năng này đã đánh bại SVN, theo đó tôi nhớ cùng một nhiệm vụ cần thiết là tạo và kiểm tra toàn bộ một cây vào các thư mục riêng biệt để đạt được cùng một mục tiêu.

Những thứ được gọi là "tính năng nâng cao của kiểm soát phiên bản phân tán" đi kèm với thời gian và bạn không cần phải tìm hiểu chúng ngay từ đầu. Đừng sợ chúng. Họ ở đây để giúp bạn, không cản trở bạn. Và không có vấn đề gì để thiết lập một kho lưu trữ trung tâm cho một DVCS.

— Rajish
nguồn
1
Đây thực sự là moot, git chỉ cần một phần đủ lớn của hàm băm để có thể định hướng, thông thường một cái gì đó ~ 6 ký tự là đủ, không phải là toàn bộ hàm băm.
— TC1
2
Trong thực tế, bạn không bao giờ vượt qua băm git xung quanh. Bạn có thể sử dụng bất kỳ tiền tố duy nhất của hàm băm, thường là 6-7 ký tự.
— JesperE
1
@JesperE: Có, nhưng số lượng phát hành SVN tăng liên tục theo thời gian, trong khi băm của Git, ngay cả khi bạn viết tắt chúng, cũng có thể là ngẫu nhiên.
— Keith Thompson
2

Với SVN, bạn có thể dễ dàng kiểm tra các phần của kho lưu trữ xuống cấp thư mục, trong khi với git, bạn có được toàn bộ kho lưu trữ, bao gồm tất cả lịch sử.

Tùy thuộc vào tình huống này có thể có một số lợi thế cho SVN

(điều này cũng có một số nhược điểm lớn như rác ".svn" ẩn trên cây thư mục của bạn).

— Richard Nichols
nguồn
3
lưu ý: không có rác .svn kể từ v1.7 - hiện tại tất cả được lưu trữ ở một vị trí.
— gbjbaanb
Điều này không chính xác - git cho phép bạn chỉ kiểm tra các tệp mà không có lịch sử và cũng có thể chỉ kiểm tra các phần của repo - các tệp đơn nếu bạn muốn. Nó phức tạp hơn một chút so với svn, nhưng khả năng là có.
— Benubird
2

"Nếu bạn có một nhiệm vụ có thể được thực hiện trong sáu giờ, tốt hơn là viết một công cụ thực hiện nó trong 20 phút, ngay cả khi việc tạo công cụ mất sáu giờ?"

Kiểm soát phiên bản phân tán là một con thú khác nhau để giải quyết. Nó đòi hỏi học tập đáng kể cho mỗi nhà phát triển. Nếu bạn có bộ đệm để phù hợp với quá trình học tập cho mỗi nhà phát triển, bạn nên chuyển sang hệ thống kiểm soát phiên bản phân tán tốt. Khi giai đoạn học tập kết thúc Kiểm soát phiên bản phân tán sẽ tốt hơn nhiều so với Kiểm soát phiên bản tập trung.

Kiểm soát phiên bản phân tán dường như là một sự kiện. Nó ở đây trong một thời gian rất dài, tốt hơn là chúng ta thích nghi với nó sớm hơn sau này. Tôi nhớ cùng một cuộc thảo luận khi SVN còn mới và mọi người đã quen với CVS, rất nhiều đối số được đưa ra vì không sử dụng SVN, nhưng cuối cùng SVN đã trở thành hệ thống kiểm soát phiên bản phổ biến nhất.

Nếu công ty được thành lập tốt với nhiều mã nguồn trong hệ thống kiểm soát phiên bản hiện có, thì việc chuyển sang một hệ thống mới là một nhiệm vụ lớn, nhưng nếu công ty nhỏ hoặc bắt đầu, việc chuyển sang kiểm soát phiên bản mới là rất dễ dàng. Nhưng nếu bạn dính vào một điều khiển phiên bản cũ hơn (trong một thiết lập mới), bạn sẽ gặp phải nút cổ chai ở đâu đó trong tương lai, nơi cuối cùng bạn sẽ phải lên kế hoạch di chuyển kiểm soát phiên bản.

Tôi đã thấy rất nhiều bình luận ủng hộ SVN, nhưng tất cả chúng đều có bản chất "SVN không tệ" hơn là "SVN tốt hơn". Vì vậy, tôi thực sự khuyên bạn nên chọn Kiểm soát phiên bản phân tán (chẳng hạn như Git) cho dự án của bạn.

EDIT Ưu điểm của GIT so với SVN

  1. Không yêu cầu máy chủ chuyên dụng Trên thực tế, cả hai đều có thể được sử dụng máy chủ w / oa.
  2. Có thể tiếp tục phát triển ngay cả khi không có kết nối mạng.
  3. Quản lý chi nhánh dễ dàng hơn nhiều.
  4. Hỗ trợ tốt hơn từ các công cụ CI như Tre

Có người đề cập đến công cụ (cho studio hình ảnh) là một lý do để gắn bó với SVN. http://gitscc.codeplex.com/ cung cấp hỗ trợ GIT cho Visual Studio.

— Thủ tướng Apeirogon
nguồn
6
SVN không xử lý tập tin nhị phân tốt hơn sau đó Git hoặc Hg.
— Tên giả
2
"Bạn sẽ gặp phải nút cổ chai ở đâu đó trong tương lai, nơi cuối cùng bạn sẽ phải lên kế hoạch di chuyển kiểm soát phiên bản ..." Xin lỗi, tôi không thể đồng ý đây là một lý do tốt để thực hiện việc di chuyển ngày hôm nay. Tôi đã làm việc trên nhiều dự án trong đó phương pháp này dẫn đến việc khiến mọi thứ trở nên phức tạp hơn mức cần thiết và dự án bị hủy bỏ từ lâu trước khi nó tận dụng được những lợi ích trong tương lai. Đôi khi đủ tốt, là đủ tốt. Bám sát YAGNI và nhận công việc hôm nay. Sẽ có đủ thời gian để lo lắng về việc di chuyển sau này. Ít nhất bạn vẫn sẽ có một dự án.
— njr101
2
Once the learning phase is over Distributed Version Control is much better than Centralized Version Control.Tôi hoàn toàn không đồng ý với điều này. Nó có thể có một số lợi ích nhận thức trong một số trường hợp, nhưng một số thứ đơn giản như số phiên bản trong svn có thể đọc được là con người là một lợi ích lớn trong nhiều tổ chức.
— TZHX
1
@apeirogon - Tất cả đều thuộc về những gì bạn sẽ đặt vào kho lưu trữ. Chỉ riêng phần đầu của một trong những kho lưu trữ chính mà tôi làm việc là 11,1 GB! Nếu tôi có nó trong một repo Git / bzr / hg, nó có thể sẽ chiếm hơn 100 GB.
— Tên giả
1
Tất nhiên, điều này là do repo cụ thể này có đầy đủ các tệp PCB và mô hình 3D, tất cả đều có định dạng nhị phân và không hiệu quả về không gian. Đề xuất ở đây (Electronics.SE, ví dụ: đối với những người lưu trữ tệp ddesign PCB, v.v.) thì rất khác nếu đó là cho ai đó lưu trữ mã nguồn.
— Tên giả
1

sẽ có bất kỳ lý do cụ thể để sử dụng Subversion những ngày đó

Ngoài hỗ trợ công cụ trong IDE (mà tôi không sử dụng) - không thực sự, không. Tất nhiên SVN có thể quen thuộc hơn nhưng đó là lý do duy nhất và tôi thấy cả Hg và Git đều rất dễ học (và rất nhanh) để học.

Vâng, có tất cả những hướng dẫn phức tạp ngoài đó mô tả cách Git là tầm thường một khi bạn hiểu rằng các nhánh chỉ là các endofunctor nội địa hóa ánh xạ các giao diện con của không gian Hilbert. 1

Tôi không hiểu điều đó. Nhưng bạn biết gì không? Nó không thành vấn đề. Bạn không cần biết bất cứ thứ gì để sử dụng Git.

Đối với hầu hết các phần, Git và Hg rất dễ sử dụng và chúng có những lợi thế rõ ràng so với SVN. Con voi trong phòng dĩ nhiên là phân nhánh: các nhánh chỉ hoạt động ở Git và Hg. Ngược lại, ở SVN, họ đau đớn nhất và tan vỡ ở mức tồi tệ nhất (hợp nhất nhiều đầu).

Tất nhiên bạn vẫn có thể sử dụng SVN. Bạn vẫn có thể sử dụng Windows XP. Tuy nhiên, phần lớn người dùng đã thử cả hai đều đồng ý rằng một trong những lựa chọn thay thế là vượt trội hơn rất nhiều.

1 Vâng, tôi hiểu rằng đây là một trò đùa. Tôi nghĩ.

— Konrad Rudolph
nguồn
Một hướng dẫn Git với các phần tử con endofunctor ánh xạ đồng nhất của không gian Hilbert? Tôi cần phải đọc nó! Nhưng điều này không đúng với Darcs, được viết bằng Haskell (mà tôi nghĩ là endofunctor đề cập đến) và lấy cảm hứng từ cơ học lượng tử (do đó là không gian Hilbert )? Tôi thực sự không thể thấy Git và HG phải làm gì với những thứ này.
— leftaroundabout
@leftaroundabout Đó là một trò đùa. Mô tả thậm chí không chính xác (theo như tôi biết). Đó là một câu chuyện ngắn về nhiều hướng dẫn bắt đầu với các nhánh git của Keith rất dễ dàng một khi bạn nhận ra rằng Tiết Trị và sau đó có một phép ẩn dụ cụ thể theo tên miền phức tạp sau nó.
— Konrad Rudolph
1
Bạn đã bao giờ nghĩ rằng tất cả những hướng dẫn quá phức tạp tồn tại vì một lý do? Và nó để làm gì? Tôi chưa bao giờ hiểu nỗi ám ảnh của đám đông DVCS với việc phân nhánh và sau đó tích hợp lại một chi nhánh cho mọi điều nhỏ nhặt. Điều đó luôn khiến tôi cảm thấy như một giải pháp tìm kiếm vấn đề. Việc tích hợp lại một chi nhánh trong SVN rất khó khăn vì đó là một điều thực sự ngu ngốc và sai lầm về mặt khái niệm , và tôi thực sự không tìm thấy bất kỳ lý lẽ nào làm cho "sản phẩm của chúng tôi làm cho việc làm sai trở nên dễ dàng hơn nhiều" rất thuyết phục.
— Mason Wheeler
1
Đối với việc thực hiện nhiều thay đổi song song, tôi sẽ thừa nhận rằng điều đó hơi đau, nhưng giải pháp phù hợp là có giá đỡ, được lên kế hoạch cho phiên bản SVN tiếp theo. Và hầu hết thời gian, nếu bạn đang thực hiện nhiều thay đổi cùng một lúc, (và đặc biệt là nếu bạn đang thực hiện một cách nhất quán!) Đó là bằng chứng của một vấn đề rộng hơn cần được giải quyết ở cấp độ tổ chức, không được bật mới công cụ. (Xem ở trên, "sản phẩm của chúng tôi làm cho việc làm sai trở nên dễ dàng hơn nhiều" và bài viết kinh điển của Joel về chuyển đổi nhiệm vụ của con người.)
— Mason Wheeler
3
@KonradRudolph Việc hợp nhất các nhánh trở lại vào thân cây chỉ hoạt động tốt trong các phiên bản mới nhất của SVN. Nó đã trở nên tốt hơn dần dần trong vài năm tới nơi nó rất tốt bây giờ.
— Adam Brussel
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.