Các điểm mạnh và điểm yếu tương đối của Git, Mercurial và Bazaar là gì? [đóng cửa]


137

Mọi người ở đây thấy gì về điểm mạnh và điểm yếu tương đối của Git, Mercurial và Bazaar?

Khi xem xét từng người trong số họ với nhau và chống lại các hệ thống kiểm soát phiên bản như SVN và Perforce, vấn đề nào cần được xem xét?

Khi lập kế hoạch di chuyển từ SVN sang một trong những hệ thống kiểm soát phiên bản phân tán này, bạn sẽ xem xét các yếu tố nào?


1
Để so sánh cụ thể về Windows giữa Mercurial và Git, hãy xem câu hỏi này: stackoverflow.com/questions/2550091/ mẹo
alexandrul

BTW, tôi muốn thấy phần trăm sử dụng các hệ thống DVCS khác nhau.
sergiol

Câu trả lời:


145

Git rất nhanh, quy mô rất tốt, và rất minh bạch về các khái niệm của nó. Mặt trái của điều này là nó có một đường cong học tập tương đối dốc. Một cổng Win32 có sẵn, nhưng không phải là một công dân hạng nhất. Git hiển thị băm dưới dạng số phiên bản cho người dùng; điều này cung cấp sự đảm bảo (trong đó một hàm băm duy nhất luôn đề cập đến cùng một nội dung; kẻ tấn công không thể sửa đổi lịch sử mà không bị phát hiện), nhưng có thể gây cồng kềnh cho người dùng. Git có một khái niệm duy nhất là theo dõi nội dung tệp, ngay cả khi những nội dung đó di chuyển giữa các tệp và xem tệp dưới dạng đối tượng cấp đầu tiên, nhưng không theo dõi thư mục. Một vấn đề khác với git là có nhiều hoạt động (chẳng hạn như rebase) giúp dễ dàng sửa đổi lịch sử (theo một nghĩa nào đó - nội dung được đề cập bởi hàm băm sẽ không bao giờ thay đổi, nhưng các tham chiếu đến hàm băm đó có thể bị mất); một số người theo chủ nghĩa thuần túy (bao gồm cả bản thân tôi) không thích điều đó lắm.

Bazaar khá nhanh (rất nhanh đối với những cây có lịch sử nông, nhưng hiện tại có quy mô kém với chiều dài lịch sử) và dễ học đối với những người quen thuộc với giao diện dòng lệnh của SCM truyền thống (CVS, SVN, v.v.). Win32 được coi là mục tiêu hạng nhất bởi nhóm phát triển của nó. Nó có một kiến ​​trúc có thể cắm cho các thành phần khác nhau và thay thế định dạng lưu trữ của nó thường xuyên; điều này cho phép họ giới thiệu các tính năng mới (như hỗ trợ tốt hơn để tích hợp với các hệ thống kiểm soát sửa đổi dựa trên các khái niệm khác nhau) và cải thiện hiệu suất. Nhóm Bazaar xem xét theo dõi thư mục và đổi tên hỗ trợ chức năng hạng nhất. Mặc dù số nhận dạng id sửa đổi duy nhất trên toàn cầu có sẵn cho tất cả các phiên bản, revnos cây-cục bộ (số sửa đổi tiêu chuẩn, gần giống với những cái được sử dụng bởi svn hoặc các SCM thông thường khác) được sử dụng thay cho băm nội dung để xác định các sửa đổi. Bazaar có hỗ trợ "kiểm tra nhẹ", trong đó lịch sử được lưu trên máy chủ từ xa thay vì sao chép xuống hệ thống cục bộ và được tự động chuyển qua mạng khi cần; hiện tại, điều này là duy nhất trong số các DSCM.

Cả hai đều có sẵn một số hình thức tích hợp SVN; tuy nhiên, bzr-svn có khả năng hơn đáng kể so với git-svn, phần lớn là do sửa đổi định dạng phụ trợ được giới thiệu cho mục đích đó. [Cập nhật, kể từ năm 2014: SubGit của sản phẩm thương mại bên thứ ba cung cấp giao diện hai chiều giữa SVN và Git, có thể so sánh về độ trung thực với bzr-svn và được đánh bóng hơn đáng kể; Tôi mạnh mẽ khuyến cáo việc sử dụng nó trên của git-svn khi ngân sách và hạn chế việc cấp phép cho phép].

Tôi đã không sử dụng Mercurial rộng rãi và vì vậy không thể nhận xét chi tiết về nó - ngoại trừ lưu ý rằng nó, như Git, có địa chỉ băm nội dung để sửa đổi; cũng như Git, nó không coi các thư mục là các đối tượng hạng nhất (và không thể lưu trữ một thư mục trống). Tuy nhiên, nó nhanh hơn bất kỳ DSCM nào khác ngoại trừ Git và có tích hợp IDE tốt hơn nhiều (đặc biệt là đối với Eclipse) so với bất kỳ đối thủ nào. Với các đặc điểm hiệu suất của nó (chỉ thua một chút so với Git) và hỗ trợ IDE và đa nền tảng vượt trội, Mercurial có thể hấp dẫn đối với các đội có số lượng thành viên đáng kể win32 centric hoặc IDE.

Một mối quan tâm trong việc di chuyển từ SVN là các giao diện GUI và tích hợp IDE của SVN đã trưởng thành hơn so với bất kỳ SCM phân tán nào. Ngoài ra, nếu bạn hiện đang sử dụng rất nhiều tự động hóa tập lệnh preommit với SVN (nghĩa là yêu cầu kiểm tra đơn vị phải vượt qua trước khi cam kết có thể tiến hành), có lẽ bạn sẽ muốn sử dụng một công cụ tương tự PQM để tự động hóa các yêu cầu hợp nhất với các nhánh được chia sẻ của bạn.

SVK là một DSCM sử dụng Subversion làm kho lưu trữ hỗ trợ và tích hợp khá tốt với các công cụ tập trung vào SVN. Tuy nhiên, nó có các đặc tính hiệu suất và khả năng mở rộng kém hơn đáng kể so với bất kỳ DSCM chính nào khác (thậm chí cả Darcs), và nên tránh cho các dự án có khả năng phát triển lớn về chiều dài lịch sử hoặc số lượng tệp.

[Về tác giả: Tôi sử dụng Git và Perforce cho công việc và Bazaar cho các dự án cá nhân của tôi và làm thư viện nhúng; các bộ phận khác trong tổ chức của chủ nhân của tôi sử dụng Mercurial rất nhiều. Ở kiếp trước tôi đã xây dựng rất nhiều tự động hóa xung quanh SVN; trước đó tôi có kinh nghiệm với GNU Arch, BitKeeper, CVS và những người khác. Git ban đầu khá khó chịu - có vẻ như GNU Arch inasmuch là một môi trường nặng về khái niệm, trái ngược với các bộ công cụ được xây dựng để phù hợp với sự lựa chọn công việc của người dùng - nhưng tôi đã khá thoải mái với nó]


Này Tôi chỉ muốn bạn biết rằng cscvs vẫn đang được sử dụng để chạy nhập mã Launchpad và tôi đã có phiên bản Canonical được phát hành khi tôi làm việc ở đó.
ddaa

19

Steve Streeting của dự án Ogre 3D vừa (28/9/2009) đã xuất bản một bài viết trên blog về chủ đề này, nơi ông thực hiện một so sánh tuyệt vời và thậm chí trao tay của Git, Mercurial và Bazaar .

Cuối cùng, anh ta tìm thấy điểm mạnh và điểm yếu với cả ba và không có người chiến thắng rõ ràng. Về mặt tích cực, anh ấy đưa ra một bảng tuyệt vời để giúp bạn quyết định đi cùng.

văn bản thay thế

Đó là một bài đọc ngắn và tôi đánh giá cao nó.


@gavenkoa, chợ là trực quan cho những người đến từ SVN. Nếu bạn đến từ git, thì bạn có một mô hình tinh thần gần với nền tảng của chợ nhưng rất xa giao diện của nó. (... Có một lớp trừu tượng dày như vậy giữa nền tảng và giao diện là điều khiến bzr có thể thân thiện với những người quen thuộc với mô hình SVN).
Charles Duffy

2
@CharlesDuffy Mercurial cũng có tên trực quan cho các lệnh và không chết (quá trình phát triển Bazaar đã bị đình trệ 2 năm trước và Canonical từ chối nó, yea Git + github giành chiến thắng trò chơi DVCS ). Tôi không bao giờ hiểu lược đồ đặt tên git, vì vậy cá nhân thích HG. Thật quá khó để chiến đấu với những kẻ yêu thích Git ((
gavenkoa

@gavenkoa, tên lệnh cốt lõi của bzr khớp với SVN, vì vậy một lần nữa, tôi không thấy những gì có thể không trực quan về chúng (đối với người dùng SVN). Vâng, tất nhiên, phát triển là chết. Tôi không tranh luận rằng bzr là thiết thực để sử dụng - chỉ có những lời chỉ trích cụ thể được đưa ra là không đúng.
Charles Duffy

1
@gavenkoa, ... Tôi cũng được biết là bảo vệ các khía cạnh của BitKeeper, mặc dù có mối ác cảm khá lớn với các nhà phát triển / chủ sở hữu phần mềm (cơ sở của nó được ghi lại công khai ... mặc dù Larry đã gọi cho tôi một lần để mô tả về sự kết thúc của họ đã xảy ra, và tôi sẽ cho rằng bây giờ tôi hiểu cả hai mặt). Chỉ vì tôi bảo vệ SCM không có nghĩa là tôi thực sự khuyên mọi người nên sử dụng nó. :)
Charles Duffy

15

Mọi người ở đây thấy gì về điểm mạnh và điểm yếu tương đối của Git, Mercurial và Bazaar?

Theo tôi Git mạnh của là thiết kế cơ bản sạch sẽ và bộ tính năng rất phong phú. Tôi cũng nghĩ rằng sự hỗ trợ tốt nhất cho các kho lưu trữ đa chi nhánh và quản lý các quy trình công việc nặng chi nhánh. Nó rất nhanh và có kích thước kho lưu trữ nhỏ.

Nó có một số tính năng hữu ích nhưng phải mất một số nỗ lực để sử dụng chúng. Chúng bao gồm ara (chỉ mục) trung gian có thể nhìn thấy giữa khu vực làm việc và cơ sở dữ liệu kho lưu trữ, cho phép giải quyết hợp nhất tốt hơn trong các trường hợp phức tạp hơn, tăng dần và kết hợp với cây bẩn; phát hiện đổi tên và bản sao bằng cách sử dụng heuristic tương tự thay vì theo dõi chúng bằng cách sử dụng một số loại id tệp, hoạt động tốt và cho phép đổ lỗi (chú thích) có thể theo dõi chuyển động mã trên các tệp và không chỉ đổi tên bán buôn.

Một trong những nhược điểm của nó là hỗ trợ MS Windows bị tụt lại phía sau và không đầy đủ. Một nhược điểm dễ nhận thấy khác là nó không được ghi chép tốt như ví dụ Mercurial và ít thân thiện với người dùng hơn so với đối thủ, nhưng nó thay đổi.

Theo tôi Mercurial sức mạnh của nằm ở hiệu năng tốt và kích thước kho lưu trữ nhỏ, trong hỗ trợ MS Windows tốt.

Theo tôi, sự bất đồng chính là thực tế rằng các chi nhánh địa phương (nhiều chi nhánh trong một kho lưu trữ) vẫn là công dân hạng hai, và theo cách kỳ lạ và phức tạp, nó thực hiện các thẻ. Ngoài ra cách nó xử lý đổi tên tập tin là không tối ưu (nhưng lần di chuyển này đã thay đổi). Mercurial không hỗ trợ sáp nhập bạch tuộc (có nhiều hơn hai bố mẹ).

Từ những gì tôi đã nghe và đọc các ưu điểm chính của Bazaar là nó dễ dàng hỗ trợ cho quy trình làm việc tập trung (cũng là nhược điểm, với các khái niệm tập trung có thể nhìn thấy ở nơi không nên), theo dõi đổi tên của cả tệp và thư mục.

Nhược điểm chính của nó là hiệu năng và kích thước kho lưu trữ cho các kho lưu trữ lớn với lịch sử phi tuyến dài (hiệu suất được cải thiện ít nhất là cho các kho không quá lớn), thực tế là mô hình mặc định là một trang trại trên mỗi kho lưu trữ (mặc dù bạn có thể thiết lập nó để chia sẻ dữ liệu) và các khái niệm tập trung (nhưng đó cũng là từ những gì tôi đã nghe thấy những thay đổi).

Git được viết bằng C, shell script và Perl, và có thể viết script; Mercurial được viết bằng C (lõi, để thực hiện) và Python và cung cấp API cho các tiện ích mở rộng; Bazaar được viết bằng Python và cung cấp API cho các tiện ích mở rộng.


Khi xem xét từng người trong số họ với nhau và chống lại các hệ thống kiểm soát phiên bản như SVN và Perforce, vấn đề nào cần được xem xét?

Các hệ thống kiểm soát phiên bản như Subversion (SVN), Perforce hoặc ClearCase là các hệ thống kiểm soát phiên bản tập trung . Git, Mercurial, Bazaar (và cả Darcs, Monotone và BitKeeper) là các hệ thống kiểm soát phiên bản phân tán . Hệ thống kiểm soát phiên bản phân tán cho phép phạm vi công việc rộng hơn nhiều. Họ cho phép sử dụng "xuất bản khi sẵn sàng". Họ có sự hỗ trợ tốt hơn cho việc phân nhánh và sáp nhập, và cho các quy trình công việc nặng chi nhánh. Bạn không cần phải tin tưởng những người có quyền truy cập cam kết để có thể nhận được đóng góp từ họ một cách dễ dàng.


Khi lập kế hoạch di chuyển từ SVN sang một trong những hệ thống kiểm soát phiên bản phân tán này, bạn sẽ xem xét các yếu tố nào?

Một trong những yếu tố bạn có thể muốn xem xét là sự hỗ trợ cho việc rút tiền với SVN; Git có git-svn, Bazaar có bzr-svn và Mercurial có phần mở rộng chuyển tiếp.

Tuyên bố miễn trừ trách nhiệm: Tôi là người dùng Git và người đóng góp thời gian nhỏ, và xem (và tham gia) danh sách gửi thư git. Tôi chỉ biết Mercurial và Bazaar từ tài liệu của họ, các cuộc thảo luận khác nhau về IRC và danh sách gửi thư, và các bài đăng trên blog và bài viết so sánh các hệ thống kiểm soát phiên bản khác nhau (một số được liệt kê trên trang GitComparison trên Git Wiki).


FYI - bzr-svn có khả năng hơn nhiều so với git-svn, ở chỗ nó là hai chiều: Tôi có thể chạy "bzr chi nhánh svn: // ...", và sau đó hợp nhất các thay đổi của tôi trở lại máy chủ svn - nơi chúng sẽ được lưu trữ với siêu dữ liệu mà các khách hàng bzr khác sẽ nhận ra.
Charles Duffy

2
Tôi là một hg dev và tôi đã tìm hiểu một chút về thiết kế Git. Tôi rất vui khi thấy cả hai đều xử lý lịch sử theo cách hợp lý duy nhất cho cài đặt phân tán: ở mức cao, cả hai đều là biểu đồ chu kỳ của các cam kết và ở cấp độ thấp hơn, cả hai đều cho phép hiển thị tham chiếu tệp tham chiếu (các đốm màu trong Git ). Mercurial có các nhánh ẩn danh (mà AFAIK không tồn tại trong Git), nó có các nhánh được đánh dấu (rất giống các nhánh Git, nhưng không có đẩy / kéo) và nó có tên các nhánh (tên nhánh được ghi trong cam kết - chúng cũng không trong Git).
Martin Geisler


7

Mercurial và Bazaar rất giống nhau trên bề mặt. Cả hai đều cung cấp kiểm soát phiên bản phân tán cơ bản, như trong cam kết ngoại tuyến và hợp nhất nhiều nhánh, cả hai đều được viết bằng python và đều chậm hơn git. Có nhiều sự khác biệt một khi bạn đi sâu vào mã, nhưng, đối với các công việc hàng ngày của bạn, chúng thực sự giống nhau, mặc dù Mercurial dường như có động lực hơn một chút.

Git, tốt, không dành cho người không quen. Nó nhanh hơn nhiều so với cả Mercurial và Bazaar và được viết để quản lý nhân Linux. Nó là nhanh nhất trong ba và nó cũng là mạnh nhất trong ba, bởi khá nhiều. Các công cụ thao tác và cam kết của Git là không thể so sánh được. Tuy nhiên, nó cũng phức tạp nhất và nguy hiểm nhất khi sử dụng. Rất dễ mất một cam kết hoặc làm hỏng một kho lưu trữ, đặc biệt nếu bạn không hiểu hoạt động bên trong của git.


10
Mercurial thực sự ngang tầm với Git. Hiệu suất không phải là sự khác biệt lớn. Nhưng chợ, là waaaay chậm hơn Mercurial và Git.
Joshua Partogi

@jpartogi - Số hiệu suất của Bazaar đã được cải thiện nhanh hơn nhiều so với các đối thủ cạnh tranh, vì vậy tôi nên thận trọng khi đưa ra khẳng định đó - đặc biệt với việc tái cấu trúc lưu trữ có sẵn dưới dạng xem trước trong các bản phát hành hiện tại và được lên kế hoạch để mặc định trong 2.0.
Charles Duffy

6

Hãy xem so sánh được thực hiện gần đây bởi các nhà phát triển Python: http://wiki.python.org/moin/DvcsComparison . Họ đã chọn Mercurial dựa trên ba lý do quan trọng:

Lựa chọn đi với Mercurial được đưa ra vì ba lý do quan trọng:

  • Theo một khảo sát nhỏ, các nhà phát triển Python quan tâm đến việc sử dụng Mercurial hơn là ở Bazaar hoặc Git.
  • Mercurial được viết bằng Python, phù hợp với xu hướng python-dev 'ăn thức ăn cho chó của riêng họ'.
  • Mercurial nhanh hơn đáng kể so với bzr (nó chậm hơn git, mặc dù bởi sự khác biệt nhỏ hơn nhiều).
  • Mercurial dễ học hơn đối với người dùng SVN so với Bazaar.

(từ http://www.python.org/dev/peps/pep-0374/ )


1
Mozilla và Sun cũng sử dụng Mercurial vì lý do tương tự.
Joshua Partogi

2
bzr cũng được viết bằng Python, thực sự chậm hơn hg nhưng do biên độ thu hẹp nhanh chóng - và là người dùng của cả Bazaar và Mercurial, tôi / không đồng ý với khẳng định "dễ học hơn".
Charles Duffy

1
Họ vẫn đang phát triển. Tôi đã quyết định bắt đầu với Bazaar cho một DCVS vì tôi nghĩ nó dễ nhất (nhưng không nhiều trong đó) và Launchpad.net. Nó khá chậm. Git trên OSX có vẻ ổn nhưng hỗ trợ Windows kém. Vì các dự án Python và Google hiện đã áp dụng nó và vì TortoiseHg, tôi đổi sang Mercurial. Tôi nghĩ rằng Mercurial đang đạt được một khối lượng quan trọng trên Bazaar và sẽ ở đó. Và Git sẽ làm việc riêng của mình, luôn tập trung vào Posix, vì vậy sẽ không bao giờ thực sự chiếm ưu thế.
Nick

5

Sun đã đánh giá git , MercurialBazaar với tư cách là ứng cử viên để thay thế VCS của Sun Teamware cho cơ sở mã Solaris. Tôi thấy nó rất thú vị.


3
những đánh giá đó có phần lỗi thời, các phiên bản mới hơn đã thay đổi một số nhược điểm đã nêu ở đó.
hayalci

2

Một điều thiếu quan trọng trong chợ là cp. Bạn không thể có nhiều tệp chia sẻ cùng một lịch sử, như bạn có trong SVN, xem ví dụ ở đâyđây . Nếu bạn không có kế hoạch sử dụng cp, bzr là một sự thay thế tuyệt vời (và rất dễ sử dụng) cho svn.


Điều này bị thiếu bởi thiết kế - không thể thêm cp mà không tạo ra một số trường hợp khó hoặc không thể chắc chắn thực hiện Quyền kết hợp giữa một nhánh nơi một bản sao và thay đổi xảy ra và một nhánh khác có thay đổi nhưng không có bản sao .
Charles Duffy

Chắc chắn, nhưng đó là điều cần chú ý - và nó sẽ là một tính năng rất hữu ích cho nhiều trường hợp sử dụng (như tách một tệp thành hai trường hợp khác nhau và lưu giữ lịch sử cho cả hai). Trên thực tế, đó là lý do duy nhất tại sao tôi vẫn sử dụng lật đổ cho một số dự án nhất định - trong đó việc sáp nhập là không liên quan nhưng bản sao thì không
Davide

2

Tôi đã sử dụng Bazaar một thời gian mà tôi thích rất nhiều nhưng đó chỉ là những dự án nhỏ hơn và thậm chí sau đó nó còn khá chậm. Rất dễ học, nhưng không siêu nhanh. Nó là rất nền tảng x mặc dù.

Tôi hiện đang sử dụng Git mà tôi rất thích kể từ phiên bản 1.6 khiến nó giống với các VCS khác hơn về các lệnh sử dụng.

Tôi nghĩ rằng sự khác biệt chính cho trải nghiệm của tôi khi sử dụng DVCS là:

  1. Git có cộng đồng sôi động nhất và thường thấy các bài viết về Git
  2. GitHub thực sự đá. Launchpad.net vẫn ổn, nhưng không có gì thích thú với Github
  3. Số lượng công cụ quy trình làm việc cho Git là rất nhiều. Nó được tích hợp ở khắp mọi nơi. Có một số cho Bzr nhưng gần như không nhiều hoặc được duy trì tốt.

Tóm lại, Bzr rất tuyệt khi tôi cắt răng trên DVCS nhưng giờ tôi rất hài lòng với Git và Github.


Bạn có nghĩa là "bây giờ" rất hạnh phúc, trái ngược với "không" rất hạnh phúc, phải không?
Charles Duffy

Cảm ơn Charles! Bit một Freudian trượt ở đó :)
sh1mmer

1

Đây là một câu hỏi lớn phụ thuộc rất nhiều vào ngữ cảnh sẽ khiến bạn mất nhiều thời gian để nhập vào một trong những hộp văn bản nhỏ này. Ngoài ra, cả ba trong số này có vẻ giống nhau đáng kể khi được sử dụng cho các công cụ thông thường mà hầu hết các lập trình viên thường làm, vì vậy ngay cả việc hiểu được sự khác biệt cũng đòi hỏi một số kiến ​​thức khá bí truyền.

Bạn có thể sẽ nhận được câu trả lời tốt hơn nhiều nếu bạn có thể phá vỡ phân tích của mình về các công cụ này đến điểm mà bạn có câu hỏi cụ thể hơn.


Vì vậy, có thể là một câu hỏi meta: những câu hỏi nên được hỏi và các yếu tố cần xem xét là gì?
Jordan Dea-Mattson

1

Bazaar là IMHO dễ học hơn git. Git có một hỗ trợ tốt trong github.com.

Tôi nghĩ bạn nên cố gắng sử dụng cả hai và quyết định cái nào phù hợp với bạn nhất.


1
Mercurial dễ dàng như Bazaar, tương đối nhanh so với git và có hỗ trợ tốt trên Bitbucket. Vì vậy, những gì bạn có thể yêu cầu?
Joshua Partogi

1

Mọi người ở đây thấy gì về điểm mạnh và điểm yếu tương đối của Git, Mercurial và Bazaar?

Đây là một câu hỏi rất cởi mở, giáp với flamebait.

Git là nhanh nhất, nhưng cả ba đều đủ nhanh. Bazaar là linh hoạt nhất (nó có hỗ trợ đọc-ghi trong suốt cho kho SVN) và quan tâm rất nhiều đến trải nghiệm người dùng. Mercurial là một nơi nào đó ở giữa.

Cả ba hệ thống đều có rất nhiều fanboy. Cá nhân tôi là một fanboy của Bazaar.

Khi xem xét từng người trong số họ với nhau và chống lại các hệ thống kiểm soát phiên bản như SVN và Perforce, vấn đề nào cần được xem xét?

Các cựu là hệ thống phân tán. Thứ hai là các hệ thống tập trung. Ngoài ra, Perforce là độc quyền trong khi tất cả những người khác là miễn phí như trong lời nói .

Tập trung so với phi tập trung là một lựa chọn tuyệt vời hơn nhiều so với bất kỳ hệ thống nào bạn đề cập trong danh mục của nó.

Khi lập kế hoạch di chuyển từ SVN sang một trong những hệ thống kiểm soát phiên bản phân tán này, bạn sẽ xem xét các yếu tố nào?

Đầu tiên, thiếu một sự thay thế tốt cho TortoiseSVN. Mặc dù Bazaar đang làm việc trên biến thể Rùa của riêng họ , nhưng nó vẫn chưa xuất hiện, kể từ tháng 9 năm 2008.

Sau đó, đào tạo những người chủ chốt về cách sử dụng một hệ thống phi tập trung sẽ ảnh hưởng đến công việc của họ.

Cuối cùng, tích hợp với phần còn lại của hệ thống, chẳng hạn như bộ theo dõi vấn đề, hệ thống xây dựng hàng đêm, hệ thống kiểm tra tự động, v.v.


1
Đối với bản ghi, trang hiện tại ghi rõ: "Kể từ phiên bản Bazaar 1.6, TortoiseBZR được bao gồm trong trình cài đặt chính thức", do đó dường như nó đã hoàn thiện.
PhiLho

1

Vấn đề chính của bạn sẽ là đây là những SCM phân tán và do đó đòi hỏi một chút thay đổi trong suy nghĩ của người dùng. Khi mọi người đã quen với ý tưởng, các chi tiết kỹ thuật và mô hình sử dụng sẽ được đưa ra, nhưng đừng đánh giá thấp rào cản ban đầu đó, đặc biệt là trong môi trường công ty. Hãy nhớ rằng, tất cả các vấn đề là vấn đề con người.


1

ddaa.myopenid.com đã đề cập đến nó thông qua, nhưng tôi nghĩ rằng nó đáng để đề cập lại: Bazaar có thể đọc và viết vào kho SVN từ xa. Điều đó có nghĩa là bạn có thể sử dụng Bazaar cục bộ như một bằng chứng về khái niệm trong khi phần còn lại của nhóm vẫn đang sử dụng Subversion.

EDIT: Gần như tất cả các công cụ hiện có một số cách tương tác với SVN, nhưng bây giờ tôi có trải nghiệm cá nhân git svnhoạt động rất tốt. Tôi đã sử dụng nó trong nhiều tháng, với những trục trặc tối thiểu.


git cũng có giao diện vào svn, nhưng tôi chưa có cơ hội sử dụng đúng cách - utsl.gen.nz/talks/git-svn/intro.html
Cebjyre

1

Có video hay của Linus Torvalds trên git. Anh ấy là người tạo ra Git, vì vậy đây là những gì anh ấy quảng bá nhưng trong video anh ấy giải thích các SCM phân tán là gì và tại sao chúng tốt hơn sau đó tập trung vào. Có rất nhiều so sánh git (mercurial được coi là OK) và cvs / svn / perforce. Cũng có những câu hỏi từ khán giả liên quan đến việc di chuyển sang SCM phân tán.

Tôi tìm thấy tài liệu này khai sáng và tôi được bán cho SCM phân phối. Nhưng bất chấp những nỗ lực của Linus, sự lựa chọn của tôi là đồng bóng. Lý do là bitbucket.org, tôi thấy nó tốt hơn (hào phóng hơn) rồi github.

Tôi cần nói ở đây một lời cảnh báo: Linus có phong cách khá hung dữ, tôi nghĩ anh ấy muốn vui nhưng tôi không cười. Ngoài ra, video rất tuyệt nếu bạn chưa quen với SCM phân tán và suy nghĩ về việc chuyển từ SVN.

http://www.youtube.com/watch?v=4XpnKHJAok8


0

Các hệ thống kiểm soát phiên bản phân tán (DVCS) giải quyết các vấn đề khác với các VCS tập trung. So sánh chúng giống như so sánh búa và tua vít.

Các hệ thống VCS tập trung được thiết kế với mục đích có một Nguồn thực sự được ban phước, và do đó là Tốt. Tất cả các nhà phát triển làm việc (thanh toán) từ nguồn đó, sau đó thêm (cam kết) các thay đổi của họ, sau đó trở thành Tương tự. Sự khác biệt thực sự duy nhất giữa CVS, Subversion, ClearCase, Perforce, VisualSourceSafe và tất cả các CVCS khác nằm ở quy trình làm việc, hiệu suất và tích hợp mà mỗi sản phẩm cung cấp.

Các hệ thống VCS phân tán được thiết kế với mục đích là một kho lưu trữ tốt như bất kỳ kho lưu trữ nào khác và việc hợp nhất từ ​​kho này sang kho khác chỉ là một hình thức giao tiếp khác. Bất kỳ giá trị ngữ nghĩa nào mà kho lưu trữ nên được tin cậy đều được áp đặt từ bên ngoài theo quy trình, chứ không phải bởi chính phần mềm.

Sự lựa chọn thực sự giữa việc sử dụng một loại hoặc loại kia là tổ chức - nếu dự án hoặc tổ chức của bạn muốn kiểm soát tập trung, thì DVCS là không bắt đầu. Nếu các nhà phát triển của bạn dự kiến ​​sẽ làm việc trên toàn quốc / thế giới, mà không có kết nối băng thông rộng an toàn đến kho lưu trữ trung tâm, thì DVCS có lẽ là cứu cánh của bạn. Nếu bạn cần cả hai, bạn là fsck'd.


Có rất nhiều sự khác biệt đáng kể giữa CVS, SVN và VisualSourceSafe (gọi tên nhưng 3) có ảnh hưởng nghiêm trọng đến tiện ích của họ - và đây không chỉ là vấn đề về quy trình làm việc và / hoặc tích hợp.
Murph

Tôi đã sử dụng cả ba trong số đó, và về mặt kỹ thuật thì bạn đúng, nhưng từ góc độ cấp cao, câu trả lời của tôi cũng có giá trị. Kiểm soát phiên bản cho nhiều hơn một nhà phát triển là một công cụ tổ chức; miễn là công cụ đáp ứng nhu cầu của tổ chức, đó là tất cả những gì quan trọng về lâu dài.
Craig Trader
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 cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.