2012-12-19 30 views
6

Tôi có một repo git svn. Tôi có nhiều nhánh phát hành ở đây. Tôi đã chuẩn bị một bản phát hành mới và là một phần của nó, tôi đã hình dung rằng tôi sẽ làm một "git rebase" từ bản phát hành trước đó để vượt qua bất kỳ thay đổi nào chưa được sáp nhập."git rebase <branch>" trên git svn repo thay đổi đích theo dõi từ xa?

Vì vậy, tôi thiết lập các chi nhánh của tôi ...

git branch new_release remotes/svn-branches/new_release 
git branch old_release remotes/svn-branches/old_release 

Và sau đó tôi đã làm rebase ...

git checkout new_release 
git rebase old_release 
# watch it pull a bunch of commits 
git svn dcommit 
    Committing to https://svn.mysvn.net/repo/releases/old_release ... 

Sau khi tôi đã làm "svn dcommit" Tôi gần như crapped quần của tôi. Nó đã được đặt hàng chi nhánh phát hành cũ của tôi trong Subversion!

Tại sao nhánh theo dõi từ xa thay đổi do thực hiện rebase?

Làm cách nào để khắc phục tình huống mà tôi đã xâm phạm?

EDIT: Được rồi, để nhận bản thân mình ra tôi tin rằng tôi có thể làm như sau: http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo

Vì có chỉ một số ít các cam kết đã có trên hai chi nhánh new_release đã được kéo đến old_release, tôi có thể trở lại chúng bằng cách tay riêng trên repo SVN. Tôi vẫn còn bối rối về những gì đã xảy ra ở đây mặc dù.

EDITx2: Đúng, sau đây là một số bước để xác minh.

  1. Thiết lập hai chi nhánh git theo dõi từ xa cho các chi nhánh SVN
  2. Check-out một trong những chi nhánh
  3. Run git svn info và quan sát những điểm URL để đúng vị trí trong SVN
  4. Run git rebase <other_branch>
  5. Run git svn info lại và quan sát URL đã thay đổi để trỏ đến vị trí chi nhánh khác trong SVN

Trả lời

7

Có vẻ như bạn đã phạm sai lầm phổ biến khi làm việc với git-svn.

Không có thứ gì như "các nhánh theo dõi" trong git-svn. Nó luôn luôn xác định URL của chi nhánh để dcommit đến bởi lịch sử đầu tiên-cha mẹ cho đến khi cam kết đầu tiên với "git-svn-id:" chữ ký được đáp ứng. URL gần chữ ký này là URL nơi cam kết sẽ được đẩy. Nhưng lưu ý, có một kiểm tra kép: URL và bản sửa đổi gần chữ ký được so sánh với cấu trúc dữ liệu trong thư mục .git/svn/refs và nếu URL và sửa đổi mâu thuẫn với chúng (điều đó đúng với các cam kết được rebased vì rebase không chạm vào chúng cấu trúc), nó không được xem xét. Vì vậy, URL chi nhánh cũ là URL cam kết đầu tiên không bị xóa.

Nếu bạn muốn trải nghiệm Git thuần túy, bạn có thể thử SubGit làm thay thế git-svn. Kể từ 2.0 nó cho phép tạo ra một gương Git thuần khiết có thể ghi được trong kho SVN của bạn, chú ý đến việc đồng bộ hóa và đồng thời. Chạy

$ subgit configure --svn-url <SVNURL> project.git 
$ #adjust projectX.git/subgit/{config,authors.txt,passwd} 
$ subgit install project.git 
$ git clone project.git project/ 

Sau khi cài đặt, bạn có thể sử dụng nó làm kho lưu trữ Git thông thường.Vì vậy, ví dụ bạn chạy:

$ git checkout new_release 
$ git rebase old_release 
$ git push origin new_release 
+0

subgit trông rất đẹp, rất tiếc là tôi không thể cài đặt nó trên máy chủ SVN của chúng tôi, quá nhiều người dựa vào nó và có thể dễ dàng cài đặt khi mọi thứ phần lớn "đang làm việc". Làm thế nào tôi nên làm những gì tôi đã cố gắng để làm trong git-svn? – ashgromnies

+1

bạn có thể cài đặt subgit ngay trên máy của mình và chỉ định --svn-url , tức là nó có yêu cầu gần như giống như git-svn. Với git-svn ... Tôi nghĩ bạn có thể 1) checkout new_release 2) đảm bảo rằng HEAD đã cam kết thông báo với URL chính xác trong git-svn-id (ví dụ: URL new_release) 3) và lựa chọn cherry cam kết một bằng cách loại bỏ git-svn-id: chữ ký (ví dụ: sử dụng lệnh "git cherry-pick -n" và chỉnh sửa thư trước khi commit) hoặc rebase & remove chúng sau khi tất cả lệnh "git filter-branch". Thành thật mà nói, tôi không chắc chắn rằng việc loại bỏ chữ ký git-svn-id là cần thiết, nhưng tôi sẽ loại bỏ chúng tốt hơn. –

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