可能有3層Git-SVN環境？

我是Git新手（來自SVN）。想知道是否可以爲軟件開發建立一個3層環境。按3層我的意思是這樣的：可能有3層Git-SVN環境？

    SVN 
     (as top remote repo) 
        | 
       GIT 1 
    (as middle tier remote repo) 
     /     \ 
     GIT 2     GIT 3 
(local git repo)  (local git repo)

此刻我不使用中間層（Git 1）遠程回購。所以只有本地的Git repos推動對遠程SVN回購的更改。因爲最高級別的SVN回購並不總是可用（由於連接問題），我想知道是否有可能在中間放置一箇中間級Git回購（Git 1），所有客戶（Git 2和3）會推動變化，比如在一天結束時，Git 1的變化將被推到SVN。

所以問題是：這種設置可能嗎？

來源

2011-12-16 Michal M

出於好奇，爲什麼要使用SVN回購作爲頂級？只要用GIT做所有事情，不需要混合東西。 – 2011-12-16 10:28:13

這就是客戶的公司使用。沒有在這方面的選擇:( – 2011-12-16 10:28:50

當您推回到svn時，作者身份將會丟失（如果您有多個提交者，這一點很重要），因爲git-svn使用一個用戶推送更改。但更糟的是，推遲到svn的提交將被修改（將添加svn修訂版），這將使未來的工作，如果不是完全不可能的方式來痛苦。

來源

2011-12-16 10:28:47

我同意Michal的看法：三層解決方案可以整潔地解決處理分佈式git複製品時出現的糟糕網絡連接到強制性SVN頂層的問題。

我自己正是這個問題。

我也同意邁克爾說，如果你試圖以不規則的方式做到這一點，它可能會很快變得混亂。

我還沒有實施解決方案，但我有一個大概的想法是什麼樣的解決方案。

基本思想是讓GIT 1維護一個以非常可控的方式更新的未決分支。在GIT 2和GIT 3開發人員會根據他們的工作在等待中（或更好，但是，等待所花費的時間在良好定義的點標記）

讓：

主幹是一個分支跟蹤SVN主幹 - 這可能是背後的n條提交
未決用於跟蹤變化尚未承諾SVN，使得分支：
- 未決總是指合併提交
- GIT中REV-列表--merges ^軀幹未決^ 1是空的＃（沒有未決合併提交）
- 未決和未決^ 1總是sametree
增量是一個提交使得GIT中REV-列表--merges ^未決三角洲是空
未來是提交依賴於增量，使得git的轉速名單--merges ^三角洲未來是空的

然後，三角洲融入待定：

git checkout -f -B tmp delta 
git rebase --onto pending^1 pending tmp 
git checkout pending 
git merge --ff-only tmp 
git merge -s ours delta 
git branch -D tmp

未來融入待定：

git checkout -f -b tmp future 
git rebase --onto pending^1 pending tmp 
git checkout pending 
git merge --ff-only tmp 
git merge -s ours future 
git branch -D tmp

爲了整合掛起到SVN：

＃同步樹幹SVN：

git checkout trunk 
git svn rebase    # should never fail

＃***關卡樹幹這裏

＃rebase待處理^ 1到主幹上

git checkout -f -B tmp pending^1 
git rebase --onto trunk trunk tmp 
git checkout trunk 
git merge --ff-only tmp 
git svn dcommit   # could fail with a race condition 
          # rollback to *** if this happens

＃紀錄未決

git checkout -f -B tmp trunk 
git merge -s ours pending 
git checkout pending 
git merge --ff-only tmp 
git branch -D tmp 
git tag INTEGRATED-XXX pending # Every commit reachable from INTEGRATED-XXX 
           # has been integrated with SVN

合併該解決方案使用信息只（-S我們的）合併提交的未決分支記錄，承諾發起了Git中，土地一直是事實合併成一個註定要交付給svn-land的分支。

因此，儘管爲了向SVN提交提交而發生了重新綁定，但這對git-land中的任何人來說實際上都不成問題，因爲git rev-list^pending應該只顯示未整合的提交和隨後的整合週期迭代將只會重新提交這些提交。

的確，我只說明了幸福世界的情況。我也沒有說明三角洲不是一個簡單的線性偏離懸而未決的情況。

如果在待處理中存在大量未傳送的工作並且SVN重新映射失敗並且無法修復，那麼事情可能會變得非常多毛。假如你可以解決這個問題而不中止rebase你是好的。如果你不得不放棄重建，重建將變得混亂。

我打算爲此策略實施一些腳本支持，並且會在此處發佈更新以讓您知道它是如何發生的。

來源

2012-05-02 12:09:23 jonseymour

可能有3層Git-SVN環境？

回答

相關問題