2010-10-25 25 views
7

Công ty của tôi đang chuyển từ Subversion sang Mercurial. Một trong những lý do là với Hg, chúng tôi hy vọng có thể làm việc độc lập hơn.Làm thế nào để sao lưu kho Mercurial địa phương và sử dụng rebase?

Chúng tôi rất mong được sử dụng rebasing làm cách chính để cập nhật từ kho chính, ít nhất là trong phần đầu, để giữ lịch sử trong một dòng, làm cho việc chuyển đổi từ Subversion dễ dàng hơn.

Ngay bây giờ, nếu chúng ta cần làm việc độc lập, chúng tôi có hai tùy chọn: tạo một nhánh trong Subversion và cam kết ở đó (aka địa ngục hợp nhất), hoặc không cam kết gì cả. Với Mercurial, chúng tôi hy vọng có thể tiếp tục cam kết tại địa phương, và thường xuyên khởi động lại, do đó đạt được sự độc lập trong khi vẫn giữ nguyên chi phí quản lý của các chi nhánh được đặt tên.

Tất cả các âm thanh này đều mát mẻ cho đến khi sao lưu được đưa vào ảnh. Với Subversion, rõ ràng là nếu ai đó không cam kết, công việc của họ sẽ bị mất. Nhưng không cam kết trở nên bất tiện nhanh chóng (không có lịch sử, không có thông điệp tường trình, vv), vì vậy mọi người sẽ cam kết thời gian và một lần nữa tuy nhiên.

Với Mercurial nó sẽ có thể đi vào cam kết và rebasing mà không cần đẩy trong thời gian dài của thời gian, đưa nhiều công việc có nguy cơ. Vì vậy, một câu hỏi xuất hiện: làm thế nào để sao lưu nội dung trên các máy của nhà phát triển?

  • Một giải pháp là sử dụng một số phần mềm sao lưu bên ngoài, nhưng điều đó nghe có vẻ không phải là một ý tưởng hay.
  • Chúng tôi cũng có thể đẩy đến repo chính mọi lúc (thậm chí có thể tự động?), Nhưng điều này sẽ làm cho nó không thể sử dụng rebasing, và sẽ dẫn đến rất nhiều người đứng đầu lơ lửng trong chính.
  • Chúng tôi có thể đẩy tới một bản lưu trữ dự phòng và cố gắng chỉ có một đầu trong repo chính. Âm thanh này rất phức tạp.

Có cách nào khác để thực hiện việc này không? Tôi muốn tìm một giải pháp cho phép các nhà phát triển của chúng tôi sử dụng hầu hết kiến ​​thức Subversion của họ ngay từ đầu.

Trả lời

1

Bạn cũng có thể cung cấp cho mỗi nhà phát triển một repo:

 
https://example.com/repos/awesome-product 
https://example.com/repos/awesome-product-wolever 
https://example.com/repos/awesome-product-pintér 

đâu họ có thể đẩy cho tất cả họ muốn.

Nó có nghĩa là rất nhiều lủng lẳng đầu, nhưng đó có lẽ OK bởi vì không ai sẽ nhìn vào chúng cho đến khi nó đến thời gian để khôi phục ... Sau đó, bạn muốn chỉ đơn giản là yêu cầu duy nhất là tổ tiên của mũi hiện tại:

 
hg pull https://example.com/repos/awesome-product-wolever -r tip 

Nếu tôi đang sử dụng chương trình này, tôi muốn thiết lập:

 
[paths] 
backup = https://example.com/repos/awesome-product-wolever 

trong .hgrc/hgrc.

Ngoài ra, bạn có thể cung cấp cho mỗi dev một repo sao lưu toàn bộ bằng cách thiết lập này trong toàn cầu ~/.hgrc của họ:

 
[paths] 
backup = https://example.com/repos/wolever-backup 
4

Chỉ cần ném này ngoài kia: Tôi nghĩ rằng bạn đang làm cho một sai lầm. Một lịch sử tuyến tính không phải là một vấn đề lớn và kéo/hợp nhất là công việc bình thường hơn nhiều. Embrace một lịch sử phi tuyến tính và để lại rebase cho những dịp đặc biệt.

Bạn nói "Với Mercurial, chúng tôi hy vọng có thể tiếp tục cam kết tại địa phương, và thường xuyên được trả lại, do đó đạt được sự độc lập trong khi vẫn giữ nguyên chi phí quản lý của các chi nhánh được đặt tên." điều này, vì vậy không có chi phí hành chính.

Xem http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/#branching-anonymously để biết giải thích về cách các nhánh chưa đặt tên được tạo tự động sẽ cung cấp cho bạn chính xác những gì bạn muốn mà không gặp rắc rối nào.

Tôi biết nó có vẻ như dầu rắn quá tốt, nhưng bạn chỉ có thể hg pullhg mergehg push khi họ trải qua và không ai phải nghĩ về tên chi nhánh hoặc ai có gì clone, hoặc bất cứ điều gì, bạn sẽ có một trung tâm phối hợp với công việc bị ngắt kết nối.

1

Tôi nghĩ bạn đang làm sai cách.
Những gì bạn mô tả trông giống như bạn đang cố gắng đặt công cụ vào đảm bảo/thực thi một quy trình, thay vì để hỗ trợ quy trình.

Làm việc theo cách phi tập trung là một sự thay đổi lớn so với cách tiếp cận tập trung, và bằng cách cố gắng đưa ra hạn chế loại bạn mô tả sẽ có nhiều khả năng gây tổn thương nhiều hơn lợi ích cho kinh nghiệm của nhà phát triển.

Nếu bạn sợ rằng họ sẽ không thay đổi thường xuyên kho lưu trữ chính, thì bạn nên tự hỏi (và hỏi họ) "Chúng tôi đã sẵn sàng để thay đổi quy trình của chúng tôi ? " Nhiều người vẫn cho rằng DVCS sẽ mang lại sự hỗn loạn cho nhà máy phần mềm của họ. Đúng là DVCS'es không thực thi một cách tuyến tính (một điểm-của-thất bại) để làm việc, nhưng những gì mang lại sự hỗn loạn không phải là công cụ, đó là tinh thần đồng đội mà bạn xây dựng trong công ty của mình.

Bây giờ, nếu bạn CÓ PHẢI chuyển sang Mercurial (vì nó đã được bán cho các cấp quản lý, hoặc bất cứ điều gì), nhưng cảm thấy thoải mái hơn với cách tiếp cận SVN, với một chút "cộng", hãy thử sử dụng HgSubversion đầu tiên. Di chuyển sẽ vẫn dễ dàng sau này.

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