Di chuyển từ ClearCase sang SVN/Mercurial

Question

Tại nơi làm việc, chúng tôi đang sử dụng ClearCase ngay bây giờ. Tuy nhiên, có rất nhiều chi phí cần thiết, đặc biệt là khi ai đó làm điều gì đó ngu ngốc (như xóa một chế độ xem với nhiều lần đặt trước trên thân cây ...). Vì chúng tôi đang cố gắng giảm chi phí của chúng tôi và càng nhẹ càng tốt, chúng tôi đã vượt qua khả năng vứt bỏ CC và điều gì đó nhẹ hơn (Subversion hoặc Mercurial), xem như cách chúng tôi không sử dụng 90% tính năng của CC dù sao. Điều này âm thanh hợp lý hay chúng ta sẽ kinh doanh Ferrari của chúng tôi trong một toa xe ga?

Answer 1

Từ kinh nghiệm của tôi, ClearCase thực sự có rất nhiều chi phí và chúng tôi quản lý rất nhiều với SVN.

Tôi bỏ phiếu, "hạ cấp" (thực sự là UPGRADE). ;)

Answer 2

Tôi chắc chắn sẽ cân nhắc việc chuyển từ chữ viết hoa sang lật đổ nâng cấp!

Answer 3

Tôi đồng ý với các áp phích trước đó. Việc bỏ rơi sản phẩm IBM và chuyển sang một sản phẩm điều khiển nguồn mở sẽ không bị hạ cấp chút nào. Bạn sẽ có thể hạnh phúc hơn với những công cụ nhẹ hơn và dễ sử dụng hơn. Trong cửa hàng của chúng tôi, chúng tôi đang trong quá trình chuyển từ CVS sang SVN và khá hài lòng với kết quả.

Answer 4

Bốn đề xuất mà bạn chuyển đổi. Nếu bạn không sử dụng các tính năng, đó là một lựa chọn kinh doanh kém để đi với các giải pháp thương mại giá.

Hiện tại, có một chi phí liên quan đến giải pháp "miễn phí". Cả SVN lẫn Mercurial đều không cung cấp hỗ trợ cấp thương mại cho bạn. Nếu đây là một vấn đề, và nó chắc chắn có thể được cho một số tình huống, bạn có thể không muốn làm điều đó.

Trong số hai bạn đề cập, SVN là một trong những bạn nên chọn nếu bạn hiện đang sử dụng kho lưu trữ VC tập trung. Không chỉ mô hình hoạt động của SVN đơn giản và trực quan, mà SVN đơn giản là tài liệu và cộng đồng nhà phát triển tốt nhất mà tôi từng thấy trong một dự án mã nguồn mở. Danh sách gửi thư của người dùng thật tuyệt vời, nhà phát triển đáp ứng và chịu trách nhiệm với người dùng của họ và Red Bean book là phần hướng dẫn sử dụng mã nguồn mở tốt nhất viết ra ở đó.

Answer 5

Tôi không gặp vấn đề với "chuyển đổi" của bạn. Nó sẽ là bản nâng cấp nếu bạn không có nhiều dự án phụ thuộc lẫn nhau bằng UCM.

Tôi quản lý cả SCM (ClearCase và Subversion) và khuyên bạn nên sử dụng Subversion cho các dự án độc lập từ nhỏ đến trung bình. Tuy nhiên, hãy đảm bảo rằng các nhà phát triển của bạn không quen với chế độ xem động của ClearCase: đó là gói gọn của hệ thống tệp cho phép người dùng truy cập truy cập tệp từ mạng. Theo hiểu biết của tôi, ClearCase là người duy nhất có quyền truy cập đó.

Và đi vào xem xét các mô hình ca:

• ClearCase là tập trung (mỗi tập tin bạn nhận được là chỉ đọc, và bạn kiểm chỉ các tập tin mà bạn làm việc)
• Subversion là kho lưu trữ tập trung (mỗi tệp bạn nhận được là đọc-ghi, bạn kiểm tra tất cả các tệp đã sửa đổi/thêm/xóa trong một lần commit nguyên tử)

Answer 6

Điều quan trọng tôi đã học là, quan trọng hơn sản phẩm là quy trình .

Nếu bạn đã triển khai ClearCase (CC) sử dụng kiểu SVN, thì SVN sẽ hoạt động tốt và rẻ hơn lot. Mặt khác, nếu bạn sử dụng phân nhánh hoãn lại, chế độ xem theo nhãn, và năng động (hoặc có thể), chúng tôi sử dụng lợi thế lớn trong việc tiết kiệm thời gian và công sức, và cải thiện độ tin cậy, bạn sẽ hối tiếc một cách nghiêm túc những tính năng này. (Chưa kể quản lý xây dựng, UCM, vv)

tôi thấy hầu hết mọi người sử dụng lựa chọn đầu tiên, mà cũng giống như sử dụng một chiếc Ferrari tham gia giao thông giờ cao điểm ...

Ví dụ? Xác định nhãn GA, SP1, SP2 (bạn có thể có nhiều bản phát hành giữa GA và SP1 tùy thích, không liên quan và nhớ, nhãn CC KHÔNG giống SVN). GA là bản phát hành cơ sở của bạn, SP1 là bản phát hành hiện tại của bạn. SP2 là bản phát hành tiếp theo của bạn. Phiên bản hiện tại dựa trên GA và SP1. Bản phát hành tiếp theo dựa trên GA, SP1 và SP2 (xem thông số kỹ thuật cấu hình CC)

Bắt đầu QA. Phát triển đang thực hiện công việc liên tục cho "bản phát hành tiếp theo" và người dùng có thể tham khảo (không thay đổi) GA và SP1 và có thể áp dụng SP2. Bảo trì đang làm việc để sửa chữa các lỗi do QA tìm thấy và có thể tham khảo GA và áp dụng SP1.

Trường hợp 1: Trong ClearCase, hành vi chỉ áp dụng nhãn SP1 làm cho bản sửa lỗi tự động có sẵn cho nhóm phát hành Dev SP2. Không có công việc. Nada, Zero.

Trong Subversion, bạn sẽ thực hiện thay đổi trên chi nhánh QA, và sau đó (hy vọng, hãy nhớ) di chuyển thay đổi sang SP2.

Trường hợp 2: Trước khi bạn hỏi, chắc chắn, nếu bạn thêm thay đổi SP2, bạn sẽ phải nhánh để thêm thay đổi tiếp theo cho SP1, vì nó sẽ ở hầu hết các hệ thống.

Trong thế giới của tôi, số thực tế: Trường hợp 1 đã xảy ra 122 lần cho SP cuối cùng của tôi (8 SP mỗi năm). Hơn 800 thay đổi mỗi năm tôi không phải thực hiện trong ClearCase tôi sẽ phải thực hiện nếu tôi sử dụng mô hình Subversion.

Trường hợp 2 đã xảy ra 6 lần kể từ đầu năm 2002 khi chúng tôi cài đặt CC.

Nhìn vào quy trình , không chỉ là sản phẩm .

(Xin lỗi về độ dài, nó không bắt đầu dài như vậy :-)

Answer 7

Chúng tôi đã chuyển từ ClearCase LT sang SVN và yêu thích nó. Chúng tôi đang tiết kiệm rất nhiều tiền mặt trong phí bảo trì và mọi thứ đang hoạt động tốt như trước đây.

Tôi chỉ ước mình đã điều tra Git hoặc một cái gì đó như thế trước khi tôi đề nghị SVN.

Answer 8

Tôi muốn được biết về cấu trúc chi nhánh của bạn được thiết lập như thế nào.

Tại sao người dùng làm việc trên 'thân cây' của sản phẩm của bạn? (Tôi cho rằng điều này có nghĩa là chi nhánh chính của bạn). Các chi nhánh phát triển sẽ không ngăn cản các nhà phát triển của bạn ảnh hưởng đến thân chính?

Tại sao bạn không thể giới thiệu trình kích hoạt trên tập lệnh rmview ngăn người dùng xóa chế độ xem trong khi vẫn có các lần kiểm tra? Đây là một bài tập khá nhỏ, và có rất nhiều nguồn trực tuyến (và tôi chắc rằng StackOverflow sẽ cung cấp cho bạn câu trả lời nếu bạn hỏi!).

Một gợi ý khác là, nếu bạn có tiền đã đầu tư vào các sản phẩm của IBM (do đó sẵn sàng chi tiền cho môi trường SCM được hỗ trợ thương mại), bạn có thể muốn xem Team Concert và Jazz.

Answer 9

Tôi vừa dành vài tuần qua tại công việc mới của mình để tìm kiếm các công cụ quản lý SCM (Quản lý cấu hình phần mềm) và ALM (Quản lý vòng đời ứng dụng) để thay thế CVS và hỗ trợ việc áp dụng Agile.

Nếu bạn đang tìm kiếm thứ gì đó sẽ hỗ trợ SCM đúng với sự phát triển song song và phân nhánh thì có thể có nhiều lựa chọn thay thế hơn bạn nhận ra.

Đối với một giải pháp SCM đơn giản nhìn vào những điều sau đây:

• Accurev: Đây là một công cụ SCM có hỗ trợ cho các dòng/song song phát triển dựa. Nó cung cấp một trình duyệt luồng rất tốt cho bạn một cái nhìn đồ họa về các luồng của bạn và cho phép bạn đồ họa thúc đẩy các thay đổi như các vấn đề hoặc như changeset (thực thi các khuyến khích nguyên tử của một tập hợp các tệp nguồn). Nó có một bộ theo dõi vấn đề được xây dựng để cung cấp cho bạn quản lý thay đổi và cho phép bạn làm việc theo cách thức dựa trên nhiệm vụ. Với AccuFlow, bạn có thể kiểm soát nhiều hơn các thay đổi của mình với quy trình làm việc và Accubridge cho phép bạn tích hợp IDE.
• Seapine Surround: Đây là một công cụ tìm kiếm đẹp hoạt động tốt cho phân nhánh nhưng không hoàn toàn nâng cao như Accurev. Điều tuyệt vời về Seapine là tích hợp với công cụ theo dõi vấn đề của họ, TestTrack Pro và cả giải pháp quản lý trường hợp thử nghiệm của họ TestTrack TCM (kết hợp với TestTrack Stuido). Cuối cùng, họ cũng có QA Wizard Pro là một công cụ kiểm thử tự động trên web và winforms.
• PureCM: Đây là một sự thay thế đó là khá phổ biến nhưng tôi đã không nhìn nó rất chi tiết
• Perforce: Một thay thế trong không gian này mà tôi đã không quá ấn tượng với nhưng nó có một số các tính năng thích hợp thú vị như khả năng so sánh và hợp nhất hình ảnh.
• SCM nhựa: Sản phẩm hiển thị nhưng rất thú vị khi xem xét.

Tất cả các giải pháp này cung cấp hỗ trợ phân nhánh tốt hơn ClearCase đều có các khái niệm như hộp cát dành cho nhà phát triển (thay vì sử dụng chế độ xem điên trong ClearCase) và ảnh chụp nhanh verions. Về cơ bản một nhánh chỉ đọc, giống như một đường cơ sở.

Nếu bạn có một triển khai Rational rộng bạn có thể muốn xem xét những lựa chọn thay thế:

• MKS Liêm: A nice tốt để cùng nhau sản phẩm trong đó có công cụ quản lý danh mục đầu tư tuyệt vời với một tốt đẹp được xây dựng trong chạy thử nghiệm lượt xem. Tất cả các công cụ của nó rơi vào một IDE và rất tùy biến.
• Serena CM: Một lần nữa một bộ phần mềm đủ tốt với các công cụ mở rộng xung quanh giải pháp ALM cốt lõi.Phần quản lý danh mục đầu tư rất lớn và có rất nhiều sự hỗ trợ quy trình kinh doanh với các thành phần Mashup của họ và cũng hỗ trợ cho việc tạo mẫu.
• Telelogic: Trớ trêu thay bây giờ là một phần của IBM và sắp được IBM hợp lý. Giải pháp SCM của nó (Telelogic Change và Synergy) dễ dàng là tốt nhất mà tôi đã thấy với khả năng quảng bá thay đổi mã một cách rõ ràng bởi tác vụ thành một nhánh xây dựng bản phát hành.

Tất cả các giải pháp trên hỗ trợ các khái niệm SCM giống như Accurev vv nhưng rõ ràng là kết thúc nhiều hơn cho sản phẩm cuối cùng và là quy mô doanh nghiệp.

Hiện tại, chúng tôi đã thu hẹp lựa chọn của mình xuống MKS hoặc Telelogic.

Điểm lớn nhất của tôi về vấn đề này là có rất nhiều giải pháp ngoài mạng giữa ClearCase và CVS/Subversion mang tính thương mại nhưng lại rẻ tiền.

Hy vọng điều này đã được sử dụng.

Answer 10

Những điều tôi thích về ClearCase rằng tôi đã không thể làm tốt hoặc ở tất cả các công cụ SCM khác:

1. Làm việc với các ngành phát triển là không đau. Trong CC (UCM), bạn làm việc trong luồng của mình (chi nhánh a.k.a.) và "phân phối" một loạt công việc cho luồng tích hợp. Trong khi đó, các nhà phát triển khác cũng làm như vậy. Trình tích hợp (có thể là một trong các nhà phát triển) sau đó thực hiện một số thử nghiệm trên luồng tích hợp và đảm bảo mọi thứ đều được xây dựng và có thể kiểm tra khói, sau đó đề xuất một đường cơ sở mới, bao gồm công việc từ tất cả các nhà phát triển. Trong khi đó, bạn tiếp tục làm việc trong chi nhánh của bạn. Lần tới bạn muốn phân phối (hoặc trước đó nếu bạn thích), bạn sẽ thấy một đường cơ sở mới có sẵn, vì vậy bạn nhập vào luồng của mình. Trong thực tế, bạn buộc phải rebase nếu một đường cơ sở mới có sẵn. Tôi đã thử làm điều này trong Microsoft Team Foundation Server, và SVN. Đầu tiên, tôi không thể tìm ra cách để thực thi một chính sách giống như việc thực thi CC, vì vậy tôi phải đi tìm xem bản sửa đổi nào của tôi từ lần hợp nhất cuối cùng, và những gì đã được thực hiện trong thân từ đó, và sau đó hợp nhất từ ​​thân cây vào nhánh của tôi. Sau đó, khi tôi muốn kết hợp công việc mới của tôi vào thân cây, tôi đã phải hợp nhất tất cả những thứ tôi vừa nhập vào nhánh của tôi, cộng với công việc mới của tôi.
2. Chi nhánh nhà phát triển có lợi cho các đánh giá mã hiệu quả. Khi tôi đang sử dụng CC, chúng tôi đã xem xét mọi thứ. Thực tế, mặc dù, đánh giá mất thời gian và chúng tôi cần tiếp tục làm việc. Mỗi phần công việc tương ứng với một hoạt động trong CC. Chỉ khi quá trình xem xét hoàn tất, chúng tôi phân phối hoạt động đó cho luồng tích hợp. Nếu đánh giá yêu cầu thay đổi, tôi có thể quyết định thực hiện thay đổi trong hoạt động tôi đã thực hiện tác phẩm gốc (miễn là không có thay đổi nào được thực hiện đối với các tệp đã thay đổi trong hoạt động đó), tạo hoạt động mới để giải quyết các thay đổi đánh giá hoặc có thể thổi bay toàn bộ hoạt động và bắt đầu lại (một lần nữa, miễn là không có thay đổi tiếp theo nào được thực hiện). Trong TFS và SVN, một khi bạn cam kết một cái gì đó, bạn không thể quay trở lại dễ dàng mà không thổi đi công việc tiếp theo. Vì vậy, chúng tôi đã phải tìm một số cách khác để hiển thị các thay đổi của chúng tôi cho các nhà phát triển khác. Điều này đã kết thúc được diffs chuyển đổi sang các trang web, nhưng vẫn còn, chúng tôi không thể đi vào với nhiều công việc mà không có nó nhận được pha trộn với công việc đang chờ xem xét.
3. Phát triển đa nền tảng dễ dàng hơn với chế độ xem động. Tôi chỉ có SVN để so sánh ở đây, vì vậy có lẽ Mercurial hoặc những người khác thì tốt hơn. Mục tiêu của tôi là thực hiện các thay đổi, xây dựng, thử nghiệm, gỡ lỗi trên cả nền tảng Linux và PowerPC (và Windows cho một dự án khác) và cam kết một changeset duy nhất khi tôi hài lòng nó hoạt động trên tất cả các nền tảng. Đối với các bản xây dựng PowerPC, chúng tôi đã có một máy trạm mặt trời (truy cập chế độ xem động) mà chúng tôi đã sử dụng để xây dựng và thử nghiệm cho một mục tiêu. Nó chậm, vì vậy chúng tôi đã thực hiện hầu hết mã hóa và gỡ lỗi trên Linux, sau đó xây dựng và thử nghiệm trên PowerPC trước khi thử nghiệm cuối cùng trên mục tiêu (PowerPC) và cuối cùng là đăng ký. Một cách xung quanh đây là chia sẻ tệp mạng. Một vấn đề tôi đã thấy ở đây là phiên bản không tương thích giữa Linux svn và TortoiseSVN trên Windows. Nếu bạn cho Tortoise vào bản sao repo Linux, nó sẽ thay đổi.svn tập tin, và Linux svn sau đó than phiền phiên bản là quá mới. (Chúng tôi đã không thể nâng cấp các hộp Linux của chúng tôi lên một svn đủ mới vì nền tảng chúng tôi đã chọn cho một mục tiêu.) Vì vậy, tôi không thể sử dụng công cụ khác biệt Windows của tôi trong một repo Linux svn. Nếu tôi đi theo cách khác, bằng cách sử dụng Windows check-out và Linux gắn repo Windows, các symlink không được bảo toàn (cần thiết trong quá trình xây dựng Linux).

Tôi không đồng ý, việc duy trì ClearCase là cơn ác mộng và sẽ mất phí. Nhưng một khi nó được thiết lập, nó có thể cung cấp cho một môi trường phát triển rất tốt. Đặc biệt là khi bạn bắt đầu tích hợp với ClearQuest (theo dõi lỗi, chúng tôi cũng sử dụng để theo dõi các đánh giá mã).

Như một người trả lời khác đã nêu, câu trả lời cho bạn phụ thuộc nhiều vào nhu cầu của quá trình của bạn.

Answer 11

Âm thanh với tôi như bạn sẽ hài lòng với git/mercurial và có lẽ không phải trong SVN. OTOH, tất cả kinh nghiệm của tôi rõ ràng là tẻ nhạt và không yêu thương, vì vậy tôi sẽ xem xét bất kỳ hành động "trốn thoát" nào là một điều rất tốt.

Hệ thống phân tán có vẻ giống như chúng khớp với quy trình làm việc của bạn tốt hơn.

Answer 12

Tôi khuyên bạn nên đọc HG Init - hướng dẫn của Joel Spolsky về cách chuyển từ SVN sang Mercurial.

Như một số câu trả lời trước đã đề cập, SVN và ClearCase về cơ bản làm việc theo cùng một mô hình, vì vậy khi bạn đọc bài viết, bạn có thể thay thế khá nhiều sự xuất hiện của từ "Subversion" cho "ClearCase" và áp dụng nó vào tình hình.

Đây là bản ghi cuối cùng đã thuyết phục tôi để bắt đầu sử dụng Mercurial tại nơi làm việc.

Answer 13

Trong công ty trước đây của tôi (quy trình CMMi), khoảng 100 nhà phát triển/người thử nghiệm/nhà tích hợp làm việc với ClearCase (CC) với 3 quản trị viên toàn thời gian (thêm 2 lần bán tự nguyện). Trừ khi bạn sử dụng phần quản lý cấu hình (đường cơ sở), bạn nên chuyển sang SCM hiện đại. Tính năng cơ bản là mạnh mẽ: trong SCM truyền thống, khi bạn cập nhật/rebase bạn nhận được bản sửa đổi mới nhất theo mặc định. Đường cơ sở là một tập hợp các thành phần phần mềm ở bản sửa đổi 'tương thích' nhất định để đảm bảo bản dựng là ok. Trong một số cách, nó giống như xây dựng phụ thuộc (tức là Maven, Ant Ivy). Khi các nhà phát triển rebase (cập nhật) trên đường cơ sở, họ nhận được những gì nên được "xây dựng".

Bây giờ nhìn lại từ công ty mới của tôi (cửa hàng Agile), chúng tôi sử dụng SVN và Mercurial và tôi nghĩ CC là nỗi đau hàng ngày. Với CC để làm việc trên một dự án (kho lưu trữ), bạn có một chế độ xem, tạo một hoạt động, sau đó kiểm tra một tệp. Một số đồng nghiệp sợ tạo ra chi nhánh :). Với SVN và Mercurial, chúng tôi không có một số vấn đề như vậy với các máy khách GUI của họ. Các nhà phát triển cam kết 10 lần trên cơ sở hàng ngày. So với người CC sẽ kiểm tra một lần một ngày.

Thực tế CC có nhiều thời gian chờ trên mạng và chậm, chi phí giấy phép cao và cần quản trị viên toàn thời gian. Vì vậy, những lợi ích ngoại trừ việc quản lý cấu hình là gì.

Trên Mercurial, luồng công việc nhẹ hơn. Đối với dự án hiện tại của chúng tôi, một trong những sai lầm bằng cách cam kết các tập tin không nguồn. Lịch sử Hg là bất biến. Chúng tôi không có quản trị viên. Một nhà phát triển đã nhân bản một dự án mới trong nửa ngày. Trong Clearcase, bạn sẽ cần hỏi chuyên gia chỉ để sao lưu tệp đã xóa :). Để tạo một repo mới, bạn yêu cầu quản trị viên của bạn :)

Sau khi di chuyển khỏi ClearCase, bây giờ tôi thực sự hài lòng với SVN và đặc biệt là Mercurial. Vì vậy, việc chuyển từ ClearCase sang Mercurial sẽ thực sự nhẹ trong quá trình xử lý, € và bạn nhận được nhiều năng suất hơn.

Bây giờ lựa chọn giữa SVN và Mercurial? Bạn nên tự hỏi mình liệu kho lưu trữ tập trung hay phi tập trung. Bạn có thể thực hiện tìm kiếm nhanh trên stackoverflow.

Tôi đã không thích các sản phẩm Rational của IBM trong các giải pháp mã nguồn mở trang nhã.

Nếu bạn đọc và hiểu điều này, bạn nên đặt tiêu đề "Nâng cấp từ chữ viết hoa thành svn-mercurial".

Đã thêm: Bỏ qua phía sau ngưỡng giới thiệu, trong khi Mercurial, Subversion & Git được đề xuất rõ ràng. http://martinfowler.com/bliki/VersionControlTools.html
Bạn cũng có thể kết hợp Mercurial & Clearcase. Đọc đoạn "Nhiều VCS"