Đã dành cả buổi sáng để cố gắng kiểm tra một cái gì đó - bây giờ tôi nhận ra rằng tôi đã mất một vài ngày làm việc.

Nó đã xảy ra trước đây - và dường như là sự xuất hiện phổ biến với SourceSafe. SourceSafe có thể được sử dụng thành công mà không gặp sự cố không và nếu có thì làm thế nào?

Quan điểm của tôi là đơn giản, di chuyển sang một cái gì đó càng sớm càng tốt. Sẽ không mất nhiều thời gian (1-2 tuần WAG) và cho dù việc di chuyển mất bao lâu, thật dễ dàng để chi trả cho việc quản lý. Một chút thời gian để di chuyển tương đương với kiểm soát nguồn vững chắc và rất ít khả năng mất mã nguồn. Thực hiện tìm kiếm nhanh trên google cho "những câu chuyện kinh dị an toàn nguồn" hoặc tương tự nếu ông chủ của bạn nghi ngờ.

Tệ nhất SCM. Không bao giờ.

Tất cả những gì sai trong SCM được thể hiện trong VSS. Ngay cả StarTeam cũng tốt hơn Source Safe. Source Safe là Internet Explorer 1 của thế giới kiểm soát phiên bản: hoàn toàn bị áp đặt bởi bất kỳ triển khai nào khác.

Tôi đã sử dụng nó như thế nào?

Quy trình công việc điển hình của tôi để hoàn thành công việc là

1. Kiểm tra dự án
2. Khóa tất cả các tệp (để tránh hợp nhất với bất kỳ ai đã mở cánh cổng địa ngục vô hồn)
3. Đã làm việc của tôi
4. Mỗi ngày kiểm tra những thay đổi của tôi trong
5. Đã kiểm tra lại tất cả một lần nữa và khắc phục tất cả các vấn đề với tích hợp
6. Đã kiểm tra lại

So với Subversion, ở trên là đáng cười (ngoài việc kiểm tra bạn đã không phá vỡ bản dựng).

Hạn chế đối với thực tiễn lập trình nhóm của tôi

Đây là những quy tắc mà nhóm phải làm việc để làm cho nó hoạt động. Số dặm của bạn có thể thay đổi.

1. Một người chỉ có thể chỉnh sửa một tập tin (Trời giúp bạn nếu họ đi nghỉ)
2. Đừng phân nhánh quá khó để quản lý
3. Không bao giờ cố gắng quay lại phiên bản trước

Những gì có thể được thực hiện?

Polarion có một bộ công cụ tốt để chuyển từ nguồn như Safe Safe sang Subversion (SVN), đây là tiêu chuẩn thực tế hiện nay trong hầu hết các doanh nghiệp để kiểm soát phiên bản nguồn mở. Subversion không yêu cầu phải có sẵn máy chủ để cho phép đăng nhập (không giống như GIT hoặc Mercurial được thiết kế cho các nhóm ngoại tuyến phân tán).

Thay đổi Kiểm soát nguồn của bạn thành SVN / Mercurial / Git và không bao giờ nhìn lại!

Chúng tôi đã đưa nó ra khỏi hoạt động khoảng một năm trước.

Nó đã xảy ra nhiều lần mà những gì tôi đã đăng ký vào tối hôm trước chỉ không có ở đó vào sáng hôm sau. Tôi đã không thấy thú vị bởi vì nó trông giống như tôi đã không hoàn thành công việc của mình. Vì tôi mới vào công ty nên nó có thể gây nguy hiểm cho tôi.

Chúng tôi đã chuyển sang TFS và nó đã hoạt động trơn tru kể từ đó.

Quan điểm của tôi?

Có những cái tốt hơn dễ sử dụng hơn, an toàn hơn để sử dụng và hoàn toàn miễn phí. Tại sao phải sử dụng nó cả?

Đây là một lĩnh vực phát triển nơi chúng ta có nhiều sự lựa chọn; hầu hết, hoặc tất cả, tốt hơn VSS.

• Lật đổ
• Thủy ngân
• Git
• Hơn

Sử dụng SourceSafe trong một hoạt động thương mại cũng giống như làm nóng tòa nhà bằng cách đốt các hóa đơn đô la.

Vào năm 2000, công ty tám nhà phát triển của tôi có thể đã mất 5-10% năng suất vì các lỗi cơ sở dữ liệu VSS trung bình hai lần mỗi ngày. Nó chỉ ở mức thấp vì chúng tôi đã đi đến các bản sao lưu hàng giờ.

Kể từ khi chuyển từ VSS sang Perforce, svn và git, tôi chưa bao giờ có cơ sở dữ liệu SCM bị hỏng.

Tôi có thể bị bỏ phiếu xuống địa ngục về điều này, nhưng ..

VSS thực sự khiến bạn gặp khó khăn, đến mức bạn không thể dung hòa được bất kỳ loại thực tế nào cần thiết để nhận ra rằng repo bây giờ của bạn không phải là lỗi của bạn.

Xin vui lòng, không bao giờ sử dụng nó.

đã sử dụng nó trong nhiều năm - đó là giải pháp mặc định, vì nó đã có sẵn. Nó đã cắn tôi khá nhiều lần, nhưng quán tính rất khó vượt qua

sau đó tôi đã phải sử dụng nó từ xa qua VPN và thậm chí các đăng ký nhỏ cũng giống như nhét một viên gạch qua lỗ kim . Nhanh hơn là tìm các tệp đã thay đổi, nén chúng, gửi email, điều khiển từ xa vào máy vault nguồn, giải nén chúng và kiểm tra mã từ máy vault nguồn.

Chuyển sang Mercurial. Tôi có thể sao chép toàn bộ cơ sở mã nguồn trên VPN trong vòng một phút. Và tôi không còn sợ phân nhánh.

Không bao giờ quay trở lại.

Đó là một sự gớm ghiếc. Nhưng vẫn tốt hơn là không có gì.

Tôi đã sử dụng nó trong một thời gian dài (gần 10 năm) mà không gặp phải bất kỳ vấn đề nào (kể cả trong các đội tôi đang làm việc mặc dù mã của chúng tôi có xu hướng được phân chia khá tốt để tránh xung đột và tương tự).

Nhưng có quá nhiều câu chuyện về mất dữ liệu để tiếp tục sử dụng nó khi có những lựa chọn thay thế nguồn mở đáng tin cậy ngoài kia.

Chỉnh sửa: Từ các bình luận, tin nhắn dường như tránh được mọi thứ phức tạp (phân nhánh, hợp nhất, xung đột) và có lẽ bạn vẫn ổn. Bất cứ điều gì nhiều hơn và bạn đang đi vào lãnh thổ rủi ro.

Ngay cả MS cũng phản đối nó ủng hộ TFS.

Đối với một cửa hàng solo hoặc thực sự nhỏ làm việc trong Visual Studio 6 hoặc một cái gì đó cũ hơn thì có thể vượt qua và tốt hơn là không có gì. Tôi nghĩ rằng có rất nhiều sự cường điệu về việc nó tệ như thế nào, nhưng sau đó chỉ mất một trường hợp mất công việc có giá trị để làm bạn thất vọng về một sản phẩm (vì lý do chính đáng). VSS đã có chỗ đứng của mình và tôi tin rằng nó ít nhất đã khuyến khích rất nhiều nhà phát triển, những người không sử dụng công cụ SCM nào để tập thói quen, nhưng giống như nhiều công nghệ hiện nay nó đã lỗi thời.

Sau 3 năm sử dụng, phàn nàn và gửi đến người quản lý của tôi vì tất cả các lựa chọn hợp lý / tiên tiến hơn ngoài kia, tôi chưa bao giờ thực sự gặp vấn đề với VSS, nhưng tôi cũng chưa bao giờ có lựa chọn nào.

Quan điểm của tôi là nó vừa hút vừa thổi.

Phần khó chịu nhất về nó không phải là phiên bản khủng khiếp và khả năng phân nhánh khó hiểu, nhưng hộp danh sách trên menu tệp không cho phép bạn nhấn phím mũi tên phải để mở rộng.

Thật sự rất đau đớn.

Quan điểm của tôi về VSS? Tôi đã từ chối một vài lời mời làm việc (được trả lương rất cao) vì họ yêu cầu "thành thạo VSS". Và tôi chắc chắn có một vài người khác ở đây cũng làm như vậy.

Bạn không chỉ phải chịu đựng vấn đề tham nhũng nguồn tiềm năng (cần phải đủ lý lẽ để quản lý thay thế nó), mà bạn còn phải sống với bản sao lưu lúng túng và không có khả năng làm việc hiệu quả như một nhóm làm việc trên các luồng công việc khác nhau.

Tìm một SCM khác (bất kỳ cái nào khác) và xem cách dễ dàng phân nhánh và hợp nhất. Hãy nghĩ về những lúc bạn phải sao chép các tệp ra khỏi giải pháp VSS của mình và giữ chúng ở một nơi khác trong khi bạn quay lại để sửa lỗi về mã 'sản xuất'.

Đối với các cú đá, chỉ cần cài đặt GIT - trỏ nó vào các tệp VSS của bạn và xem GASP hai lập trình viên có thể làm việc dễ dàng như thế nào trên các phần khác nhau của cùng một tệp TẠI THỜI GIAN, sau đó phần mềm kết hợp thông minh các thay đổi của bạn ... SCM các công cụ nên được nhiều hơn là chỉ sao lưu nguồn.

Quan điểm của tôi về VSS? Đã sử dụng nó trong một thời gian dài thường xuyên (vẫn được sử dụng thường xuyên cho các thành phần cũ hơn) nhưng đó là thế kỷ XX cho nhóm của chúng tôi:

• Rất không đáng tin cậy
• Chi nhánh không sử dụng được
• Hỗ trợ phiên bản rất kém, bạn có nhãn nhưng (giống như các chi nhánh) không thực sự có thể sử dụng được

Tôi có tất cả những điều trên: chọn một trong những lựa chọn thay thế nguồn mở tốt hơn (ngay cả CVS cũ) hoặc, nếu công ty của bạn có một loại đăng ký MSDN, TFS .

• khóa mặc định của nó đã làm chậm các nhà phát triển và không ai muốn gây rối với thiết lập của nó
• nó không tích hợp tốt với các dịch vụ khác, ví dụ như một ứng dụng web quản lý dự án
• nó sẽ không hoạt động tốt với máy chủ CI theo kế hoạch của chúng tôi

Công cụ Team Foundation 2010 mới được cho là sẽ giúp ích rất nhiều và cố gắng thoát khỏi những phần tồi tệ của VSS. Nhưng cốt lõi là nó vẫn dựa vào VSS , đó là lý do tại sao chúng tôi chuyển sang SVN.

chỉnh sửa - Tôi hiểu rằng TFS hoàn toàn mới, nhưng khi thử nghiệm nó, nhiều nhà phát triển tôi đã hỏi có cảm giác rất giống với nó. Lý do tôi nói 'ở cốt lõi' là vì tôi nhớ rằng đã xem các tệp TFS được tạo trong giải pháp của mình trông giống như các VSS đã tạo. Đây là từ quan điểm của nhà phát triển, thậm chí có thể không biết về công nghệ đằng sau VSS hoặc TFS hoặc bất kỳ SCM nào khác. Xin lỗi vì sự nhầm lẫn.

Ngày trước, tôi đã được cài đặt SCCS theo XENIX. VSS, trong Visual Studio 6, đối với tất cả các lỗi và sự cố đều có những ưu điểm riêng biệt. Tôi vẫn sử dụng nó cho các dự án nhỏ và tôi không còn sử dụng SCCS trong bất kỳ phiên bản nào.

Tôi không thể hiểu tại sao mọi người muốn badmouth VSS. VSS không được phân phối và kiểm soát phiên bản phân tán là

1. tốt hơn
2. cho phép kiểm soát phiên bản không phân phối trong thực tế

Xin vui lòng đọc này .