$ sudo aptitude install git-svn将 git-svn 独立安装是因为 git-svn 软件包有着特殊的依赖，即依赖 Subversion 的 perl 语言绑定接口，Debian/Ubuntu 上由 libsvn-perl 软件包提供。当 git-svn 正确安装后，就可以使用 git svn 命令了。但如果在执行 git svn --version 时遇到下面的错误，则说明 Subversion 的 perl 语言绑定没有正确安装。
$ git svn --versionCan't locate loadable object for module SVN::_Core in @INC (@INC contains: /usr/share/perl/5.10.1 /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 .) at /usr/lib/perl5/SVN/Base.pm line 59BEGIN failed--compilation aborted at /usr/lib/perl5/SVN/Core.pm line 5.Compilation failed in require at /usr/lib/git-core/git-svn line 41.遇到上面的情况，需要检查本机是否正确安装了 Subversion 以及 Subversion 的 perl 语言绑定。为了便于对 git-svn 的介绍和演示，我们需要有一个 Subversion 版本库，并且需要有提交权限以便演示用 Git 向 Subversion 进行提交。最好的办法是在本地创建一个 Subversion 版本库。
$ svnadmin create /path/to/svn/repos$ svn co file:///path/to/svn/repos svndemo取出版本 0$ cd svndemo$ mkdir trunk tags branches$ svn add *A branchesA tagsA trunk$ svn ci -m "initialized."增加 branches增加 tags增加 trunk提交后的版本为 1。我们再向 Subversion 开发主线 trunk 中添加些数据。
$ echo hello > trunk/README$ svn add trunk/READMEA trunk/README$ svn ci -m "hello"增加 trunk/README传输文件数据.提交后的版本为 2。建立分支：
$ svn up$ svn cp trunk branches/demo-1.0A branches/demo-1.0$ svn ci -m "new branch: demo-1.0"增加 branches/demo-1.0提交后的版本为 3。建立里程碑：
$ svn cp -m "new tag: v1.0" trunk file:///path/to/svn/repos/tags/v1.0提交后的版本为 4。
git svn clone | v (本地Git库) | v+-> (hack...)| || v| git add| || v| git commit| |+-----+ | vgit svn rebase | vgit svn dcommit首先用 git svn clone 命令对 Subversion 进行克隆，创建一个包含 git-svn 扩展的本地 Git 库。在下面的示例中，我们使用 Subversion 的本地协议(file://) 来访问之前创立的 Subversion 示例版本库，实际上 git-svn 可以使用任何 Subversion 可用的协议，并可以对远程版本库进行操作。
$ git svn clone -s file:///path/to/svn/repos git-svn-demoInitialized empty Git repository in /my/workspace/git-svn-demo/.git/r1 = 2c73d657dfc3a1ceca9d465b0b98f9e123b92bb4 (refs/remotes/trunk) A READMEr2 = 1863f91b45def159a3ed2c4c4c9428c25213f956 (refs/remotes/trunk)Found possible branch point: file:///path/to/svn/repos/trunk => file:///path/to/svn/repos/branches/demo-1.0, 2Found branch parent: (refs/remotes/demo-1.0) 1863f91b45def159a3ed2c4c4c9428c25213f956Following parent with do_switchSuccessfully followed parentr3 = 1adcd5526976fe2a796d932ff92d6c41b7eedcc4 (refs/remotes/demo-1.0)Found possible branch point: file:///path/to/svn/repos/trunk => file:///path/to/svn/repos/tags/v1.0, 2Found branch parent: (refs/remotes/tags/v1.0) 1863f91b45def159a3ed2c4c4c9428c25213f956Following parent with do_switchSuccessfully followed parentr4 = c12aa40c494b495a846e73ab5a3c787ca1ad81e9 (refs/remotes/tags/v1.0)Checked out HEAD: file:///path/to/svn/repos/trunk r2从上面的输出我们看到，当执行了 git svn clone 之后，在本地工作目录创建了一个 Git 库 (git-svn-demo)，并将 Subversion 的每一个提交都转换为 Git 库中的提交。我们进入 git-svn-demo 目录，看看我们用 git-svn 克隆出来的版本库。
$ cd git-svn-demo/$ git branch -a* master remotes/demo-1.0 remotes/tags/v1.0 remotes/trunk$ git logcommit 1863f91b45def159a3ed2c4c4c9428c25213f956Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>Date: Mon Nov 1 05:49:41 2010 +0000 hello git-svn-id: file:///path/to/svn/repos/trunk@2 f79726c4-f016-41bd-acd5-6c9acb7664b2commit 2c73d657dfc3a1ceca9d465b0b98f9e123b92bb4Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>Date: Mon Nov 1 05:47:03 2010 +0000 initialized. git-svn-id: file:///path/to/svn/repos/trunk@1 f79726c4-f016-41bd-acd5-6c9acb7664b2我们看到 Subversion 版本库的分支和里程碑都被克隆出来，并保存在 refs/remotes 下的引用中。在 git log 的输出中，我们可以看到 Subversion 的提交的确被转换为 Git 的提交。下面我们就可以在 Git 库中进行修改，并在本地提交（用 git commit 命令）。
$ cat READMEhello$ echo "I am fine." >> README$ git add -u$ git commit -m "my hack 1."[master 55e5fd7] my hack 1. 1 files changed, 1 insertions(+), 0 deletions(-)$ echo "Thank you." >> README$ git add -u$ git commit -m "my hack 2."[master f1e00b5] my hack 2. 1 files changed, 1 insertions(+), 0 deletions(-)我们对工作区中的 README 文件修改了两次，并进行了本地的提交。我们查看这时的提交日志，会发现最新两个只在本地 Subversion 版本库的提交和之前 Subversion 中的提交的不同。区别在于最新在 Git 中的提交没有用 git-svn-id: 标签标记的行。
$ git logcommit f1e00b52209f6522dd8135d27e86370de552a7b6Author: Jiang Xin <jiangxin@ossxp.com>Date: Thu Nov 4 15:05:47 2010 +0800 my hack 2.commit 55e5fd794e6208703aa999004ec2e422b3673adeAuthor: Jiang Xin <jiangxin@ossxp.com>Date: Thu Nov 4 15:05:32 2010 +0800 my hack 1.commit 1863f91b45def159a3ed2c4c4c9428c25213f956Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>Date: Mon Nov 1 05:49:41 2010 +0000 hello git-svn-id: file:///path/to/svn/repos/trunk@2 f79726c4-f016-41bd-acd5-6c9acb7664b2commit 2c73d657dfc3a1ceca9d465b0b98f9e123b92bb4Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>Date: Mon Nov 1 05:47:03 2010 +0000 initialized. git-svn-id: file:///path/to/svn/repos/trunk@1 f79726c4-f016-41bd-acd5-6c9acb7664b2现在我们就可以向 Subversion 服务器推送我们的改动了。但真实的环境中，往往在我们向服务器推送时，已经有其它用户先于我们在服务器上进行了提交。而且往往更糟的是，先于我们的提交会 造成我们的提交冲突！我们现在就人为的制造一个冲突：使用 svn 命令在 Subversion 版本库中执行一次提交。
$ svn checkout file:///path/to/svn/repos/trunk demoA demo/README取出版本 4。$ cd demo/$ cat READMEhello$ echo "HELLO." > README$ svn commit -m "hello -> HELLO."正在发送 README传输文件数据.提交后的版本为 5。好的，我们已经模拟了一个用户先于我们更改了 Subversion 版本库。现在回到我们用 git-svn 克隆的本地版本库，执行 git svn dcommit 操作，将我们在 Git 中的提交推送的 Subversion 版本库中。
$ git svn dcommitCommitting to file:///path/to/svn/repos/trunk ...事务过时: 文件 “/trunk/README” 已经过时 at /usr/lib/git-core/git-svn line 572显然，由于 Subversion 版本库中包含了新的提交，导致我们执行 git svn dcommit 出错。这时我们需执行 git svn fetch 命令，以从 Subversion 版本库获取更新。
$ git svn fetch M READMEr5 = fae6dab863ed2152f71bcb2348d476d47194fdd4 (refs/remotes/trunk)15:37:08 jiangxin@hp:/my/workspace/git-svn-demo$ git st# On branch masternothing to commit (working directory clean)当我们获取了新的 Subversion 提交之后，我们需要执行 git svn rebase 将我们 Git 中未推送到 Subversion 的提交通过变基（rebase）形成包含 Subversion 最新提交的线性提交。这是因为 Subversion 的提交都是线性的。
$ git svn rebaseFirst, rewinding head to replay your work on top of it...Applying: my hack 1.Using index info to reconstruct a base tree...Falling back to patching base and 3-way merge...Auto-merging READMECONFLICT (content): Merge conflict in READMEFailed to merge in the changes.Patch failed at 0001 my hack 1.When you have resolved this problem run "git rebase --continue".If you would prefer to skip this patch, instead run "git rebase --skip".To restore the original branch and stop rebasing run "git rebase --abort".rebase refs/remotes/trunk: command returned error: 1果不其然，变基时发生了冲突，这是因为 Subversion 中他人的修改和我们在 Git 库中的修改都改动了同一个文件，并且改动了相近的行。下面按照 git rebase 冲突解决的一般步骤进行，直到成功完成变基操作。先编辑 README 文件，以解决冲突。
$ git status# Not currently on any branch.# Unmerged paths:# (use "git reset HEAD <file>..." to unstage)# (use "git add/rm <file>..." as appropriate to mark resolution)## both modified: README#no changes added to commit (use "git add" and/or "git commit -a")15:49:30 jiangxin@hp:/my/workspace/git-svn-demo$ vi README处于冲突状态的 REAEME 文件内容。
<<<<<<< HEADHELLO.=======helloI am fine.>>>>>>> my hack 1.下面是我们修改后的内容。保存退出。
HELLO.I am fine.执行 git add 命令解决冲突
$ git add README调用 git rebase --continue 完成变基操作。
$ git rebase --continueApplying: my hack 1.Applying: my hack 2.Using index info to reconstruct a base tree...Falling back to patching base and 3-way merge...Auto-merging README看看变基之后的 Git 库日志：
$ git logcommit e382f2e99eca07bc3a92ece89f80a7a5457acfd8Author: Jiang Xin <jiangxin@ossxp.com>Date: Thu Nov 4 15:05:47 2010 +0800 my hack 2.commit 6e7e0c7dccf5a072404a28f06ce0c83d77988b0bAuthor: Jiang Xin <jiangxin@ossxp.com>Date: Thu Nov 4 15:05:32 2010 +0800 my hack 1.commit fae6dab863ed2152f71bcb2348d476d47194fdd4Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>Date: Thu Nov 4 07:15:58 2010 +0000 hello -> HELLO. git-svn-id: file:///path/to/svn/repos/trunk@5 f79726c4-f016-41bd-acd5-6c9acb7664b2commit 1863f91b45def159a3ed2c4c4c9428c25213f956Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>Date: Mon Nov 1 05:49:41 2010 +0000 hello git-svn-id: file:///path/to/svn/repos/trunk@2 f79726c4-f016-41bd-acd5-6c9acb7664b2commit 2c73d657dfc3a1ceca9d465b0b98f9e123b92bb4Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>Date: Mon Nov 1 05:47:03 2010 +0000 initialized. git-svn-id: file:///path/to/svn/repos/trunk@1 f79726c4-f016-41bd-acd5-6c9acb7664b2当变基操作成功完成后，我们再执行 git svn dcommit 向 Subversion 推送我们在 Git 库中的两个新提交。
$ git svn dcommitCommitting to file:///path/to/svn/repos/trunk ... M READMECommitted r6 M READMEr6 = d0eb86bdfad4720e0a24edc49ec2b52e50473e83 (refs/remotes/trunk)No changes between current HEAD and refs/remotes/trunkResetting to the latest refs/remotes/trunkUnstaged changes after reset:M README M READMECommitted r7 M READMEr7 = 69f4aa56eb96230aedd7c643f65d03b618ccc9e5 (refs/remotes/trunk)No changes between current HEAD and refs/remotes/trunkResetting to the latest refs/remotes/trunk推送之后本地 Git 库中最新的两个提交的提交说明中也嵌入了 git-svn-id: 标签。这个标签的作用非常重要，我们在下一节予以介绍。
$ git log -2commit 69f4aa56eb96230aedd7c643f65d03b618ccc9e5Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>Date: Thu Nov 4 07:56:38 2010 +0000 my hack 2. git-svn-id: file:///path/to/svn/repos/trunk@7 f79726c4-f016-41bd-acd5-6c9acb7664b2commit d0eb86bdfad4720e0a24edc49ec2b52e50473e83Author: jiangxin <jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>Date: Thu Nov 4 07:56:37 2010 +0000 my hack 1. git-svn-id: file:///path/to/svn/repos/trunk@6 f79726c4-f016-41bd-acd5-6c9acb7664b2
| 使用 git-svn 和 git-filter-branch 整理 SVN 版本库 | 2014-04-24 | 0 Comments |
|---|---|---|
| 复用 git.git 测试框架 | 2013-10-26 | 1 Comment |
| 墙不住的Git官网 | 2013-03-04 | 5 Comments |
联系客服
