Sử dụng SVN kém - Mercurial là câu trả lời?

Trong công việc, chúng tôi sử dụng SVN, nhưng chỉ trong tên. Chúng tôi không chi nhánh hoặc hợp nhất. Chúng tôi giữ hai bản sao của kho lưu trữ, một bản đóng vai trò là nhánh "thẻ" được sao chép khi chúng tôi triển khai và lưu giữ các bản sửa lỗi và ngay lập tức loại tính năng này "phải hoạt động càng sớm càng tốt". Chúng ta phải nhớ sao chép các thay đổi được thực hiện trong một bản sao sang bản sao khác ("thân cây"). Chúng tôi có một tá dự án bên trong một thư mục trong kho lưu trữ, thay vì tách chúng ra. Nói tóm lại, điều duy nhất chúng tôi sử dụng SVN là có thể cam kết. Mọi thứ khác được thực hiện thủ công.

Tôi đã đánh giá Mercurial; Tôi đã sử dụng Git trong quá khứ (Tôi là người duy nhất trong nhóm đã sử dụng DVCS) và tôi đang nhanh chóng chọn Mercurial. Tôi đang tranh luận giới thiệu Mercurial với các thành viên còn lại như là một "cách tốt hơn" để làm mọi việc vì việc phân nhánh rất nhanh chóng, việc hợp nhất trở nên dễ dàng hơn rất nhiều và chúng ta có thể cam kết mọi thứ cục bộ với nội dung trái tim của mình và chỉ đẩy chúng vào trung tâm chi nhánh khi họ đã sẵn sàng. Chúng tôi sẽ nhận được tất cả các lợi ích của SVN (và dù sao chúng tôi cũng không nhận được nhiều lợi ích vì không ai thực sự hiểu về SVN) cộng với các tính năng mới, chúng tôi không phải có hàng tấn tệp bị đảo ngược vì vậy nếu chúng tôi phải quay ngược lại chúng tôi bị lừa Quy trình làm việc có vẻ đơn giản hơn một chút - chúng ta chỉ cần nhớ rằng "Cam kết" là cục bộ và "Đẩy" giống như cam kết của SVN,

Đây có phải là một cách tiếp cận tốt để thực hiện? Hãy nhớ rằng nhóm rất linh hoạt và sẽ đồng hành cùng bất cứ điều gì sẽ cải thiện chất lượng công việc của chúng tôi và giúp chúng tôi làm mọi việc dễ dàng hơn - CIO thậm chí đã hỏi tôi khi tôi đề cập đến việc chúng tôi không sử dụng SVN như thế nào chúng ta có thể sử dụng cái gì tốt hơn? " vì vậy anh ấy cũng ở trên đó

Đúng.

Nếu bạn thay thế "SVN" bằng "Perforce" trong OP của mình, bạn sẽ gặp phải tình huống tôi gặp phải khi bắt đầu công việc hiện tại, thậm chí là sao chép thay đổi thủ công. Hai năm chúng tôi ở Mercurial và mọi người đồng ý rằng đó là một sự thay đổi lớn.

Chúng tôi có khả năng phân nhánh và hợp nhất theo từng trường hợp hỗ trợ , rất hữu ích cho QA và khả năng tạo bất kỳ số lượng chi nhánh và kho lưu trữ bất cứ khi nào chúng tôi thấy phù hợp, sau đó chúng tôi có thể xây dựng và xác minh trong máy chủ CI của mình, sau đó triển khai đến một môi trường thử nghiệm đám mây và xác minh chức năng. Điều này mang lại lợi ích rất lớn về mặt an tâm rằng khi chúng tôi triển khai trực tiếp, chúng tôi gần như chắc chắn 100% rằng nó sẽ hoạt động (sans vấn đề môi trường / DB, rõ ràng nằm ngoài phạm vi của VCS).

Về cơ bản, những gì chúng ta có được từ việc chuyển sang đồng bóng là không gian thở. Chúng tôi không còn phải lo lắng về chi phí của một chi nhánh, hoặc các phiên hợp nhất khủng khiếp chắc chắn được sử dụng để theo dõi, mọi thứ dễ dàng hơn nhiều. Chúng tôi cũng sử dụng FogBugz khá nhiều vì vậy việc liên kết với Kiln (máy chủ lưu trữ của họ) thực sự hữu ích.

Nhận xét về trang web hginit cũng được nêu ra, như một phác thảo cho quy trình kiểm soát phiên bản thực sự hoạt động (giả sử bạn điều chỉnh nó cho quy trình làm việc QA cụ thể của công ty bạn).

Lỗ hổng duy nhất có thể có trong các điều khiển phiên bản chuyển động là bạn sẽ cần một người thực sự là động lực thúc đẩy sự thay đổi, họ rất vui khi đọc được vấn đề và thực sự sử dụng công cụ này với tiềm năng tốt nhất mà bạn dường như muốn làm

Tôi không đồng ý với ý kiến ​​về quy mô nhóm và phân phối nhóm liên quan đến việc có nên sử dụng DCVS hay không. Thực sự, đó là về phân phối CODE. Nếu bạn có nhiều chu kỳ phát triển xảy ra song song, các trường hợp hỗ trợ trên hệ thống cũ hoặc một loạt các tính năng hoặc thậm chí là các hệ thống mới (mà theo âm thanh của nó bạn làm), bạn sẽ được hưởng lợi từ việc sử dụng DVCS.

Một công cụ khác có lẽ sẽ không giải quyết được vấn đề của bạn, tôi nói bạn nên đọc bài viết này, tôi thấy nó hữu ích nhất:

http://thed Dailywtf.com/Articles/Source-Control-Done-Right.aspx

Tôi nghĩ rằng điểm chính của bài viết được tóm tắt ở đây, nhưng xin vui lòng đọc nó:

Cuối cùng: Không thực sự về các công cụ

Trong tất cả thời gian tôi đã làm việc và tích hợp các hệ thống kiểm soát nguồn khác nhau, tôi đã đi đến một kết luận: đó không phải là công cụ, đó là cách bạn sử dụng nó. Đó là một tuyên bố vô cùng tồi tệ, nhưng nó có vẻ đặc biệt đúng ở đây. Khi được sử dụng để quản lý đúng các thay đổi mã nguồn - ghi nhãn cho các bản dựng, phân nhánh bằng ngoại lệ, v.v. - ngay cả hệ thống kiểm soát nguồn khó nhất (* ho * SourceSafe * ho *) sẽ vượt xa một thiết lập Mercurial với một loạt các cam kết hỗn loạn và đẩy.

Không. Công nghệ hiếm khi giải quyết loại vấn đề này.

Mercurial phức tạp hơn Subversion (vâng, phân nhánh và hợp nhất là tốt hơn và có lẽ dễ dàng hơn, nhưng mô hình của Subversion đơn giản hơn nhiều so với Mercurial). Nếu bạn đang sử dụng Subversion theo cách dũng cảm như vậy, bạn có thể sẽ sử dụng Mercurial:

• a) Đầy đủ hoặc tốt hơn
• b) Không đầy đủ, nhưng tốt hơn so với việc sử dụng Subversion hiện tại của bạn
• c) Không đầy đủ như bây giờ
• d) Tệ hơn bây giờ

c) và d) nghe có vẻ như kết quả rất có thể. Viết ra lý do tại sao bạn nghĩ rằng bạn sẽ kết thúc bằng a) hoặc b).

Tôi không thể nói về cách các nhóm lớn hoạt động, nhưng đối với các nhóm nhỏ, rất nhiều vấn đề SVN lớn đó không thực sự là vấn đề SVN ... Chúng là vấn đề phát triển. Nếu bạn không tuân theo các tiêu chuẩn phát triển hiện đại (quan trọng nhất là thực hiện tích hợp liên tục), thì phiên bản sẽ biến thành mớ hỗn độn chính xác mà bạn mô tả ... Trước khi chuyển sang một hệ thống mới, hãy chắc chắn thực hiện phân tích nguyên nhân gốc thực sự về vấn đề của bạn ...

Không. Công cụ không thay thế phương pháp luận.

Nếu bạn không sử dụng Subversion như SCM , bạn có thể không sử dụng Mercurial cũng (và nó sẽ xảy ra có lẽ hầu hết)

SVN có thể làm những gì bạn cần nó để làm và không cần phải đổi ngựa giữa dòng cho một khoản thanh toán đáng ngờ.

Bất cứ điều gì bạn làm, bạn sẽ phải vượt qua một vấn đề niềm tin. Ai đó phải có khả năng thuyết phục mọi người thay đổi quy trình làm việc của họ. Điều này không dễ dàng ngay cả trong những trường hợp tốt nhất, ngay cả khi bạn có logic và sự thật về phía bạn. Đó là một trong những điều khó nhất để làm trong một tổ chức. Nếu bạn làm hỏng nó hoặc nó trở nên khó khăn, bạn sẽ mất niềm tin và sẽ rất khó để lấy lại niềm tin đó.

Có một vài điều mà tôi biết mọi người đã thử thành công. Có lẽ một trong số họ sẽ làm việc cho nhóm của bạn:

1. Mang theo một "huấn luyện viên" để cung cấp một loạt các hội thảo cho đội. Điều này có thể sẽ phải là một người bên ngoài (trớ trêu thay, thường thì nhiều đội dễ dàng tin tưởng người ngoài hơn là tin vào ai đó trong đội). Đó phải là người biết nội dung của cô ấy từ bên ngoài và có thể dạy những kỹ năng này cho mọi người ở mọi cấp độ hiểu biết một cách hiệu quả và đưa ra một kế hoạch thực dụng để đưa VCS mới (*) vào quy trình làm việc của nhóm.

2. Bắt đầu một dự án "skunk-works" để lái thử và xác nhận VCS mới trên một dự án phụ nhỏ. Chọn một vài nhà phát triển "alpha" sẵn sàng thử những thứ mới và đừng bận tâm đến việc thử nghiệm một loạt các thử nghiệm không thành công. Khi skunk-works có thể chứng minh những cải tiến không thể chối cãi trong quy trình làm việc, sau đó bạn có thể cố gắng đưa nó ra cho các thành viên còn lại và bạn có một vài nhà truyền giáo để giúp bạn làm điều đó.

(*) bởi "VCS mới" Tôi không nhất thiết có nghĩa là đồng bóng hay git, nó cũng có thể là SVN (được thực hiện đúng).