2012-11-30 33 views
6

Chúng tôi có một dự án có dữ liệu và mã, được gộp vào một kho lưu trữ Mercurial duy nhất. Dữ liệu cũng quan trọng như mã (nó chứa các tham số cho logic nghiệp vụ, một số đầu vào, v.v.) Tuy nhiên, định dạng của các tệp dữ liệu thay đổi rất hiếm và thay đổi các tệp dữ liệu một cách độc lập khỏi mã.Ưu điểm và nhược điểm để giữ mã và dữ liệu trong các kho lưu trữ riêng lẻ

Một lợi thế của kho lưu trữ thống nhất là chúng tôi không phải theo dõi nhiều bản sửa đổi: nếu chúng ta cần tạo lại kết quả từ lần chạy trước, chúng tôi chỉ cần cập nhật hệ thống thành số sửa đổi duy nhất được lưu trữ trong nhật ký đầu ra.

Một bất lợi là nếu chúng tôi sửa đổi dữ liệu trong khi nhiều đầu hoạt động, chúng tôi có thể mất các thay đổi dữ liệu trừ khi chúng tôi sao chép thủ công các thay đổi đó vào từng đầu.

Có bất kỳ ưu điểm/khuyết điểm nào khác để tách mã và dữ liệu thành các kho lưu trữ riêng biệt không?

Trả lời

1

Nhiều Repos:

  • ưu:

    • component-based approach (bạn xác định một nhóm các file mà có thể phát triển một cách độc lập với người khác ra)
    • đặc điểm kỹ thuật cấu hình: bạn liệt kê các tham chiếu (ở đây "các bản sửa đổi") mà bạn cần cho bạn r hệ thống để làm việc. Nếu bạn muốn sửa đổi một phần mà không thay đổi một phần khác, bạn cập nhật danh sách đó.
    • nhái phần: nếu bạn không cần tất cả các thành phần, bạn có thể chỉ sao chép những file bạn muốn (không áp dụng trong trường hợp của bạn)
  • khuyết điểm

    • quản lý cấu hình : bạn cần phải theo dõi cấu hình đó (thường là qua repo chính, đăng ký subrepos)
    • trong trường hợp của bạn, dữ liệu phụ thuộc hoàn toàn vào các phiên bản nhất định của dự án (bạn có thể có dữ liệu mới ion của dự án)

Một repo

  • ưu
    • system-based approach: bạn nhìn thấy module của bạn như là một hệ thống (dự án và dữ liệu).quản lý
    • repo: tất cả trong một
    • liên kết chặt chẽ giữa các module (mà có thể làm cho tinh thần cho dữ liệu)
  • khuyết điểm
    • truyền dữ liệu (khi nào, như bạn đề cập, một số TRỤ là đang hoạt động)
    • sửa đổi trung gian (không phản ánh tính năng mới, nhưng chỉ vì một số thay đổi dữ liệu)
    • bản sao lớn hơn (không liên quan ở đây, trừ khi dữ liệu của bạn bao gồm mã nhị phân lớn)

Đối với dữ liệu phi nhị phân, với những thay đổi thường xuyên, tôi vẫn sẽ giữ chúng trong repo cùng.

+0

Điều đó rất hữu ích, cảm ơn bạn. Tôi giả sử bạn xử lý việc truyền dữ liệu theo cách thủ công, bằng cách sao chép nó vào đầu khác (hoặc cùng một lúc, hoặc khi bạn nhận ra hai đầu sẽ không hợp nhất)? – max

+0

@max: vâng, trừ khi tôi ngăn chặn chúng (http://mercurial.selenic.com/wiki/TipsAndTricks#Prevent_a_push_that_would_create_multiple_heads), sau khi thử hợp nhất (http://kiln.stackexchange.com/questions/1696/how-to -fix-multiple-heads) – VonC

0

Có, bạn nên tách mã và dữ liệu. Giữ cho bạn mã trong điều khiển phiên bản và dữ liệu của bạn trong cơ sở dữ liệu.

Tôi thích kiểm soát phiên bản vì tôi là một lập trình viên từ hơn mười năm và tôi thích công việc này.

Nhưng trong những tháng cuối cùng tôi nhận ra: Dữ liệu không được trong kiểm soát phiên bản. Đôi khi rất khó cho một người quen thuộc với git (hoặc một hệ thống điều khiển phiên bản khác) để "để nó đi".

Bạn cần một ORM tốt hỗ trợ di chuyển giản đồ cơ sở dữ liệu. Việc di chuyển (sơ đồ và datamigrations) được giữ trong điều khiển phiên bản, nhưng dữ liệu thì không.

Tôi biết câu hỏi của bạn là về việc sử dụng một hoặc hai kho lưu trữ, nhưng có lẽ câu trả lời của tôi sẽ giúp bạn có được một điểm nhìn khác.

Các vấn đề liên quan