2012-01-26 30 views
5

Chúng tôi có một kho lưu trữ subversion không chuẩn mà chúng tôi muốn chuyển đổi sang Git. Vấn đề là tôi không thực sự biết bắt đầu từ đâu để đảm bảo rằng chúng tôi giữ được lịch sử đầy đủ nhưng không kết thúc với một mớ hỗn độn hoàn chỉnh.Cách xử lý nhập khẩu phụ không chuẩn cho Git

Kho lưu trữ của chúng tôi có 6 năm lịch sử cuối cùng cho bộ sản phẩm của công ty chúng tôi và đã trải qua nhiều cấu trúc lại. Trong mọi trường hợp, chúng tôi có nền tảng mã nền tảng cốt lõi và sau đó là một số dự án/plugin kết hợp theo những cách khác nhau trên nền tảng cốt lõi.

Cặp đôi đầu tiên của năm đã được cấu trúc như:

-- plugin1 
    - trunk 
    - branches 
    - tags 
-- pluginX 
    - trunk 
    - branches 
    - tags 
-- trunk (core platform) 
    - <various sub dirs) 
-- branches (various feature branches of the entire repository) 
    - refactoring1 
    - refactoringX 
-- tags (various tags of customer releases of full respository) 
    - customerX_1.x 
-- vendor (vendor drops and tracking of 3rd party source deps) 
    - 3rd_party_code_A 
    - 3rd_party_code_X 

Theo thời gian chúng tôi đã thêm một vài chi tiết các thư mục là thư mục gốc bao gồm:

-- releases (replaced tags; branches for released stable versions of repos) 
-- sandbox (area for misc projects of interest; should have been new repo) 

Sau đó, chúng tôi làm sạch này lên và kết thúc với:

-- trunk 
    - platform 
    - plugin1 
    - pluginX 
-- stable (stable release branches of trunk) 
    - 1.1 
    - 1.2 
-- tags (release points; marks a point on a stable branch) 
    - 1.1.1 
    - 1.1.2 
-- vendor 
-- sandbox 
-- releases (copies of old releases of interest) 

Vì vậy, đó là lịch sử của chúng tôi. Những gì chúng tôi muốn kết thúc với hy vọng là sạch hơn nhiều. Ngay bây giờ chúng ta đang nghĩ về cơ sở của kho git trông như thế này (về cơ bản là một bản sao của thư mục 'trunk' trước đó).

- platform 
- plugin1 
- pluginX 

Branches: 
    - stable/1.1 
    - stable/1.2 
Tags: 
    - rel/1.1.1 
    - rel/1.1.2 

Chúng tôi muốn đặt sandbox và nhà cung cấp vào kho lưu trữ của riêng họ. (không chắc chắn làm thế nào để làm điều này, nhưng có lẽ có một cách để nhập khẩu chỉ một tập hợp con của một kho svn)

Theo như các chi nhánh và thẻ, chúng tôi muốn mã từ 'ổn định' để kết thúc như là chi nhánh, mã từ 'thẻ' để kết thúc dưới dạng thẻ thành ổn định.

Đối với lịch sử cũ hơn từ cấu trúc ban đầu, chúng tôi muốn giữ càng nhiều lịch sử càng tốt nhưng không muốn làm ô nhiễm kho lưu trữ mới. Ví dụ, nếu chúng ta có thể nhìn lại và thấy những thay đổi đã xảy ra trên các nhánh tái cấu trúc sẽ là tuyệt vời nhưng không hoàn toàn cần thiết.

Hiện tại chúng tôi đang tranh luận về cách tiến hành và cách để mọi thứ được tái cơ cấu và nhập khẩu một cách rõ ràng. Ít nhất chúng ta cần là một cách để có một lịch sử đầy đủ của nền tảng và mã plugin trên cả hai cấu trúc tái cấu trúc trước đó. Nếu có thể, chúng tôi cũng muốn nhận được thông tin ổn định và thẻ từ cấu trúc kho lưu trữ gần đây nhất.

Có ai có đề xuất về cách thực hiện việc nhập này không?

Ví dụ:

  • Có thể giữ đầy đủ lịch sử qua tái cơ cấu?
  • Chúng ta có nên viết lại kho lưu trữ lật đổ bằng cách nào đó để xóa nó trước khi nhập và nếu có thì làm thế nào?
  • Chúng ta có nên nhập toàn bộ lịch sử và sau đó tái cấu trúc nó trong Git và như thế nào?
  • Bất kỳ ý tưởng nào về cách làm cho việc nhập này trở nên sạch sẽ?
+0

plugin1 và pluginX về cơ bản là bản repos độc lập với thân cây/nhánh/thẻ của chính nó, đúng không? – prusswan

+0

Đó là cách họ bắt đầu nhưng chúng tôi thấy rằng nó không hoạt động tốt vì mã tất cả thay đổi cùng một lúc. Vì vậy, chúng tôi chuyển sang cấu trúc kho lưu trữ thứ hai. Cấu trúc đó hoạt động rất tốt cho chúng ta bây giờ và chúng tôi muốn giữ nó với Git, chỉ quan tâm đến việc làm thế nào để giữ cho lịch sử cùng đi. – Allen

+0

Để giữ lịch sử đầy đủ, tôi cho rằng đó là vấn đề tìm ra nhánh nào nên ánh xạ đường dẫn nào, và rất nhiều kiên nhẫn (nhân bản git-svn mất rất nhiều thời gian cho svn với lịch sử sâu). Về cơ bản những thân cây đó sẽ trở thành nhánh git anyway (mặc dù bạn có thể chỉ định một trong số chúng là trunk/master vốn vẫn là một nhánh) – prusswan

Trả lời

4

Tùy thuộc vào trường hợp của bạn, git-svn (với tùy chọn mặc định là --follow-parent) có thể chỉ thực hiện thủ thuật như vậy. Điều đầu tiên bạn nên làm là thử một vài lệnh git-svn, viết cẩn thận các tùy chọn -T, -b-t để giúp cấu trúc thư mục.

Mặc dù vậy, bạn có thể gặp sự cố với lịch sử cấu trúc thư mục phức tạp.

Gần đây, tôi đã ở trong một tình huống rất giống nhau, di chuyển mã Subversion của công ty sang git, nơi lịch sử SVN đã trải qua quá trình tái cấu trúc rất giống với những gì bạn mô tả. Trong trường hợp của tôi, tôi cũng muốn tách các dự án khỏi một kho lưu trữ Subversion thành nhiều kho lưu trữ Git (một cho mỗi dự án).

Tôi đã có thể thực hiện một cách dễ dàng, quyết định rằng không quan trọng để di chuyển hơn một vài tháng lịch sử, vì vậy đối với mỗi dự án, tôi xác định bản sửa đổi sớm nhất là git-svn có thể xử lý một cách duyên dáng sau đó chỉ tìm nạp lịch sử bắt đầu từ đó (sử dụng git-svn -r). Đã từng xử lý các di sản VCS trước đây (VSS cho SVN, 2005), tôi biết từ kinh nghiệm rằng lịch sử lâu dài hầu như không được nhắc tới. Trong mọi trường hợp, thật dễ dàng để máy chủ Subversion cũ chạy (ở chế độ chỉ đọc), để nó có thể được sử dụng để tra cứu mọi thứ nếu cần.

Tôi không biết cách nào dễ dàng để dọn dẹp lịch sử của Subversion, ngoài việc sử dụng svndumpfilter để loại trừ các phần nhất định của nó. Tuy nhiên, nếu bạn may mắn, git-svn sẽ làm điều đúng đắn, và lịch sử sẽ thực sự trông sạch hơn trong git log hơn bao giờ hết trong svn log (do sự khác biệt về cách git nhìn vào các nhánh và thẻ).

Nói chung, sạch sẽđầy đủ của lịch sử là hai mục tiêu xung đột khi thực hiện di chuyển loại này. May mắn thay, cả hai đều thực sự bị đánh giá cao - cả hai đều hấp dẫn cảm giác thẩm mỹ của chúng tôi nhiều hơn là nhu cầu thiết thực.

CHỈNH SỬA: Mẹo phụ để vệ sinh: sử dụng tùy chọn --prefix trên git-svn, để cung cấp cho các nhánh được nhập một tiền tố duy nhất, vì có khả năng bạn sẽ có các quy ước phân nhánh khác nhau trong git và dễ dàng xem lịch sử svn sau.

+0

chỉ không quan tâm, mất bao lâu để hoàn tất quá trình tìm nạp? Phải mất hơn 4 ngày cho một repo tôi đã cố gắng với hơn 10k sửa đổi (và một địa ngục rất nhiều thẻ mà thực sự làm chậm điều) – prusswan

+1

@prusswan: Nó có thể mất một lúc. Điều đầu tiên tôi đã làm, đã được thiết lập một kho svn địa phương bằng cách sử dụng svnsync, để git-svn sẽ làm việc cục bộ. Sau đó, họ hầu như đã đi khá nhanh (lên đến 1/2 - 1 giờ cho những người chậm hơn), cũng làm việc ra một repo với hơn 10k sửa đổi. – Avi

+0

svnsync là một khả năng thú vị. cám ơn vì đã chia sẻ – prusswan

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