Difference between revisions of "Using git-svn (historical)"
(→For committers) |
|||
| (10 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | This guide is still incomplete. |
||
| + | See the [[Getting source code]] page for information about accessing the current source repository. The following information is for historical reference. Developers who are researching portions of the source code history that the Git migration omitted may find this information useful. |
||
| − | === For committers === |
||
| + | == Creating a git-svn repository == |
||
If you have commit access to the master SVN repository, you may wish to configure a git-svn repository that allows you to review and commit pull requests from contributors who do not have commit access. To make it easier for non-committers to interact with both Git and SVN, use the <code>svn://anonsvn.mit.edu/krb5</code> URL as the SVN root that git-svn writes into the commit objects. |
If you have commit access to the master SVN repository, you may wish to configure a git-svn repository that allows you to review and commit pull requests from contributors who do not have commit access. To make it easier for non-committers to interact with both Git and SVN, use the <code>svn://anonsvn.mit.edu/krb5</code> URL as the SVN root that git-svn writes into the commit objects. |
||
| − | To set up such a git-svn repository that you fetch from the master SVN repository, [XXXX test this; it looks like rewrite-root breaks on a SVK merge ticket, at least in Git 1.7.0.4 (tested on Ubuntu Lucid). also note merge ticket incompatibility] |
||
| + | If you do not have commit access, you will probably prefer to clone the public git-svn repository and ignore SVN. |
||
| + | |||
| + | === Cloning the GitHub repository === |
||
| + | |||
| + | To clone our GitHub repository and end up with a git-svn repository that you can use to commit to the master SVN repository: [XXXX needs testing] |
||
<pre> |
<pre> |
||
| − | git init krb5-gitsvn |
||
| + | git clone git://github.com/krb5/krb5-anonsvn krb5-github |
||
| − | cd krb5- |
+ | cd krb5-github |
| − | git svn init -s --rewrite-root=svn://anonsvn.mit.edu/krb5 svn+ssh://svn.mit.edu/krb5 |
+ | git svn init -s --rewrite-root=svn://anonsvn.mit.edu/krb5 --prefix=origin/ svn+ssh://svn.mit.edu/krb5 |
git svn fetch |
git svn fetch |
||
| + | git update-ref -d refs/remotes/origin/HEAD |
||
| + | git update-ref -d refs/remotes/origin/master |
||
| + | git checkout -b trunk origin/trunk |
||
| + | git branch -d master |
||
| + | </pre> |
||
| + | |||
| + | Be aware that the <code>git svn fetch</code> command (which builds your local copy of the git-svn metadata) could take about two hours to run. The <code>git update-ref</code> commands are to delete some spurious branches that are caused by the existence of a SVN branch named "HEAD" (don't ask) in our SVN repository. |
||
| + | |||
| + | The git-svn repository created using the above commands may be updated using either <code>git svn fetch</code> (updates from the master SVN repository) or <code>git fetch</code> (updates from GitHub). |
||
| + | |||
| + | Alternatively, you might use the following <code>git svn init</code> command instead of the one above: |
||
| + | |||
| + | <pre> |
||
| + | git svn init -s --commit-url=svn+ssh://svn.mit.edu/krb5 --prefix=origin/ svn://anonsvn.mit.edu/krb5 |
||
| + | </pre> |
||
| + | |||
| + | === Importing directly from SVN (not recommended) === |
||
| + | |||
| + | To set up a git-svn repository that fetches the entire commit history from the master SVN repository: |
||
| + | |||
| + | <pre> |
||
| + | git svn clone -s --rewrite-root=svn://anonsvn.mit.edu/krb5 svn+ssh://svn.mit.edu/krb5 krb5-gitsvn |
||
</pre> |
</pre> |
||
This has the advantage of fetching the commits from SVN using a secure transport. |
This has the advantage of fetching the commits from SVN using a secure transport. |
||
| ⚫ | Fetching all those revisions from <code>svn.mit.edu</code> |
||
| + | On Git 1.7.0.4 on Ubuntu Lucid, the rewrite-root causes the fetch to stop at r17632, which contains a SVK merge ticket for the merge of the trunk into <code>users/hartmans/ldap-integ</code>. |
||
| + | |||
| ⚫ | Fetching all those revisions from <code>svn.mit.edu</code> will take a really long time (possibly over 12 hours), so you may prefer alternatives that begin with cloning our existing public git-svn mirror. If you have an existing git-svn repository whose SVN root is the master SVN repository, you could use <code>git filter-branch</code> to rewrite the URLs, or start over by cloning the published git-svn mirror. |
||
| + | |||
| ⚫ | |||
| + | |||
| + | The git-svn mirror of our master SVN repository has some quirks that result from changes in git-svn behavior over various Git releases. If you run into problems as a result, it's probably easiest to start over by cloning from our public git-svn mirror. |
||
| + | |||
| ⚫ | Since release 1.6.6 of Git, <code>git-svn</code> can read merge tickets generated by SVK and SVN, and uses these merge tickets to create merge commits in Git. Some developers created git-svn repositories prior to this change in the behavior of git-svn, and these repositories have incompatible commit histories for otherwise identical tree histories. The commit that is most problematic in this way is r18200, which contains a SVK merge ticket for the merge of <code>branches/ccapi</code> into the trunk. The git-svn mirror that we host on <code>krbdev.mit.edu</code> and GitHub does not contain any merges that would be created by Git releases after 1.6.6. |
||
| ⚫ | |||
| + | If you have an existing git-svn repository that you would like to make compatible with the published git-svn mirror, you will probably need to use <code>git filter-branch</code> with some graft points that delete the extra parent commits of the merge commits. You will need to rerun <code>git svn fetch</code> afterward (which should operate locally without contacting the SVN repository if nothing has changed in SVN) to rebuild the git-svn metadata. |
||
| − | The git-svn mirror of our master SVN repository has some quirks. |
||
| + | == Using <code>git filter-branch</code> (not recommended) == |
||
| ⚫ | Since release 1.6.6 of Git, <code>git-svn</code> can read merge tickets generated by SVK and SVN, and uses these merge tickets to create merge commits in Git. Some developers created git-svn repositories prior to this change, and these repositories have incompatible commit histories for otherwise identical tree histories. The |
||
| + | The <code>git filter-branch</code> command is very powerful and easy to misuse. Reasons why you might want to use it include modifying your existing git-svn repository to match the commit history of our public git-svn repository. You will probably prefer to recreate your patches on top of a fresh clone from our git-svn repository, unless you have a particularly complicated local revision history you want to preserve. Instructions on how to use <code>git filter-branch</code> for this and related operations may appear here later if there is enough demand. |
||
Latest revision as of 18:24, 16 July 2012
See the Getting source code page for information about accessing the current source repository. The following information is for historical reference. Developers who are researching portions of the source code history that the Git migration omitted may find this information useful.
Contents
Creating a git-svn repository
If you have commit access to the master SVN repository, you may wish to configure a git-svn repository that allows you to review and commit pull requests from contributors who do not have commit access. To make it easier for non-committers to interact with both Git and SVN, use the svn://anonsvn.mit.edu/krb5 URL as the SVN root that git-svn writes into the commit objects.
If you do not have commit access, you will probably prefer to clone the public git-svn repository and ignore SVN.
Cloning the GitHub repository
To clone our GitHub repository and end up with a git-svn repository that you can use to commit to the master SVN repository: [XXXX needs testing]
git clone git://github.com/krb5/krb5-anonsvn krb5-github cd krb5-github git svn init -s --rewrite-root=svn://anonsvn.mit.edu/krb5 --prefix=origin/ svn+ssh://svn.mit.edu/krb5 git svn fetch git update-ref -d refs/remotes/origin/HEAD git update-ref -d refs/remotes/origin/master git checkout -b trunk origin/trunk git branch -d master
Be aware that the git svn fetch command (which builds your local copy of the git-svn metadata) could take about two hours to run. The git update-ref commands are to delete some spurious branches that are caused by the existence of a SVN branch named "HEAD" (don't ask) in our SVN repository.
The git-svn repository created using the above commands may be updated using either git svn fetch (updates from the master SVN repository) or git fetch (updates from GitHub).
Alternatively, you might use the following git svn init command instead of the one above:
git svn init -s --commit-url=svn+ssh://svn.mit.edu/krb5 --prefix=origin/ svn://anonsvn.mit.edu/krb5
Importing directly from SVN (not recommended)
To set up a git-svn repository that fetches the entire commit history from the master SVN repository:
git svn clone -s --rewrite-root=svn://anonsvn.mit.edu/krb5 svn+ssh://svn.mit.edu/krb5 krb5-gitsvn
This has the advantage of fetching the commits from SVN using a secure transport.
On Git 1.7.0.4 on Ubuntu Lucid, the rewrite-root causes the fetch to stop at r17632, which contains a SVK merge ticket for the merge of the trunk into users/hartmans/ldap-integ.
Fetching all those revisions from svn.mit.edu will take a really long time (possibly over 12 hours), so you may prefer alternatives that begin with cloning our existing public git-svn mirror. If you have an existing git-svn repository whose SVN root is the master SVN repository, you could use git filter-branch to rewrite the URLs, or start over by cloning the published git-svn mirror.
Merge ticket incompatibility
The git-svn mirror of our master SVN repository has some quirks that result from changes in git-svn behavior over various Git releases. If you run into problems as a result, it's probably easiest to start over by cloning from our public git-svn mirror.
Since release 1.6.6 of Git, git-svn can read merge tickets generated by SVK and SVN, and uses these merge tickets to create merge commits in Git. Some developers created git-svn repositories prior to this change in the behavior of git-svn, and these repositories have incompatible commit histories for otherwise identical tree histories. The commit that is most problematic in this way is r18200, which contains a SVK merge ticket for the merge of branches/ccapi into the trunk. The git-svn mirror that we host on krbdev.mit.edu and GitHub does not contain any merges that would be created by Git releases after 1.6.6.
If you have an existing git-svn repository that you would like to make compatible with the published git-svn mirror, you will probably need to use git filter-branch with some graft points that delete the extra parent commits of the merge commits. You will need to rerun git svn fetch afterward (which should operate locally without contacting the SVN repository if nothing has changed in SVN) to rebuild the git-svn metadata.
Using git filter-branch (not recommended)
The git filter-branch command is very powerful and easy to misuse. Reasons why you might want to use it include modifying your existing git-svn repository to match the commit history of our public git-svn repository. You will probably prefer to recreate your patches on top of a fresh clone from our git-svn repository, unless you have a particularly complicated local revision history you want to preserve. Instructions on how to use git filter-branch for this and related operations may appear here later if there is enough demand.
