Comments on Thomas Ferris Nicolaisen's blog: Git-SVN Mirror without the annoying update-ref

@tfnico, a few items you might want to consider fo...

2012-01-26T04:27:39.769+01:00

@tfnico, a few items you might want to consider for the big re-write of the big git-svn guide:

1. Use a local svn repository if possible. Yes, svnsync is your friend. Splitting up the network transfer and the svn->git migration into two separate steps will greatly speed up the entire process, even for medium-size projects.

2. Use an authors.txt file. Your git log will thank you!

3. When you don't have admin access to the svn server, jenkins can be used to poll for changes, as I wrote above.

Also, some related projects which are currently active:

* reposurgeon: http://esr.ibiblio.org/?p=4071

* svn-dump-fast-export: https://plus.google.com/u/0/106045714513828999745/posts/DAZjRkgJusw

Just an update about my jenkins job to fetch from ...

2012-01-25T09:31:24.908+01:00

Just an update about my jenkins job to fetch from svn and push to the bare repo. The snippet above was interesting but I think duplicated (poorly) what git svn fetch already does. So now I have moved the git svn fetch into the trigger script.

cd /Users/james/src/git-svn/git-test-fetch
fetchinfo="$(git svn fetch)"
[[ $? -ne 0 || ${#fetchinfo} -eq 0 ]] && exit 1 #the fetch either failed or found no change
read d <<< $(echo "$fetchinfo" |awk '/^r/ {print $1}') #description
cat <<- _EOD
< cause$z>< pre>
$(git svn log --oneline --show-commit --remotes -${d// *r/:})

$fetchinfo
< /pre>< /cause>
< description$z>$d< /description>
_EOD

I'm glad you like it! Feel free to suggest imp...

2012-01-21T16:15:42.835+01:00

I'm glad you like it! Feel free to suggest improvements. In particular on MS/Win it would need cygwin, whereas rewriting in groovy could make it easier to use there.

Thanks again for the very helpful git-svn guide!

Tanks for the tip, James! If I ever get around to ...

2012-01-21T12:15:44.942+01:00

Tanks for the tip, James! If I ever get around to doing the big re-write of the big git-svn guide, I'll include this.

Anyone following along here may find this snippet ...

2012-01-21T08:07:44.342+01:00

Anyone following along here may find this snippet useful:

test $(git svn find-rev $(git log --all --oneline -n 1 |awk '{print $1}')) -ne $(svn info $(git config --local svn-remote.svn.url) |awk '/^Revision:/ {print $2}')

I am using it with the Jenkins ScriptTrigger plugin to poll for when the svn Revision no longer matches the latest in the fetching repo, in order to automate the mirroring.

Of course, if you have admin access to the svn repo you should probably just set up a commit hook there.

FYI, the output looks like this:
+++ git log --all --oneline -n 1
+++ awk '{print $1}'
++ git svn find-rev 90fcd3c
++ awk '/^Revision:/ {print $2}'
+++ git config --local svn-remote.svn.url
++ svn info file:///Users/james/src/svn-test
+ test 77 -ne 77

Hi James, thanks for commenting! Yes, after creat...

2012-01-13T10:35:11.916+01:00

Hi James, thanks for commenting!

Yes, after creating the bare repo, the "default branch" has to be set to be trunk like this:

git symbolic-ref HEAD refs/heads/trunk

I'm not really sure why I didn't include that step in this guide. I think I did do it in my JavaZone presentation, so I must have discovered that after I wrote the original guide. I'll see if I get a chance to work that in. Maybe write a completely overhauled guide some day :)

After a little more reading and playing around it ...

2012-01-11T06:35:20.683+01:00

After a little more reading and playing around it looks like I could just as well done the following to fix up the bare repo, to create the master branch and use trunk to set the start-point.

$git branch master trunk

I tried this method a few times today and kept get...

2012-01-11T06:22:14.308+01:00

I tried this method a few times today and kept getting snagged when cloning the bare repo. Kept getting "warning: remote HEAD refers to nonexistent ref, unable to checkout."

Inside the bare repo I found that HEAD pointed to refs/heads/master but the master branch did not exist. So I edited HEAD to use refs/heads/trunk and was able to proceed. Everything is looking fine so far.

This was on MacOSX 10.6.8 with git 1.7.8.3.

@Gin: To be honest, I've never tried svn init ...

2011-11-14T20:12:34.067+01:00

@Gin: To be honest, I've never tried svn init twice in the same repository. It could be that it works fine, and the old configuration is properly overwritten. Maybe you have to remove the old svn-remote first, and/or the .git/svn folder. Try it out, and let me know. (but if you're worried about corrupting your working git-svn clone, make a copy of it first).

It would be great if a simple 'git svn init...

2011-11-14T16:13:34.085+01:00

It would be great if a simple 'git svn init' worked. I was just concerned about the metadata (.git/svn/{.metadata,refs}) and stuff that might take a lot of time to rebuild. In contrast, the pure git-counterpart 'git remote rename' feels fast and safe.

If a simple 'git-svn init --prefix..' followed by a 'git svn rebase' will rebuild the metadata quickly and safely, that's great. Why shall I use "clean clones"? What kind of mess are referring to: e.g old stuff in .git/svn dir, or anything else?

Hmm, I think that git-svn needs to be re-initializ...

2011-11-14T15:52:12.086+01:00

Hmm, I think that git-svn needs to be re-initialized (with the --prefix parameter), and to avoid any mess, I've done this in clean clones (so far).

However, this all takes place on the developer's machines. There's no need to change anything with the fetching/bare repos. So the developers can clone their old repo locally (fastest), add the proper mirror remote, and do git svn init with the --prefix=mirror/.

For me most of the work was rebuilding the IDE configuration files that were scattered around in the repository work tree.

Good idea - thanks for that too! I'd still pre...

2011-11-14T15:40:09.247+01:00

Good idea - thanks for that too!
I'd still prefer to do it once (on the server), rather than setting it up on the growing numbers of developer boxes. I guess there is not easy way to share repo configuration (apart from nasty tricks to commit them too) - I'd be happy to be wrong one this.

Also, do you think it's easy and fast to migrate to this -synced-prefix setup? (the repo is big)
I guess I could do a 'git remote rename oldmirror svn' , where 'svn' is default; but I'd prefer that one to 'mirror' instead.. can't see anything obvious on man git-svn. Any ideas? thanks again.

Here's a nice one-liner for the above setup: ...

2011-11-14T15:32:11.513+01:00

Here's a nice one-liner for the above setup:

git config remote.mirror.pushurl WARNING_USE_SVN_DCOMMIT_INSTEAD_OF_PUSH

This will cause developers to see an error message when trying to push to the bare repo (mirror).

Gin: Perhaps a more practical way to avoid acciden...

2011-11-14T15:24:45.680+01:00

Gin: Perhaps a more practical way to avoid accidents is to have each developer disable the push configuration in their local repositories:

http://stackoverflow.com/questions/527833/how-to-configure-git-to-avoid-accidental-git-push

Good point, thanks Thomas. I'd probably want t...

2011-11-14T15:20:48.830+01:00

Good point, thanks Thomas. I'd probably want to ensure that trouble doesn't strike (most our devs are new to git and might do mistakes). However, I'd prefer not making the whole mirror repo read-only (some of as are pushing pure-git branches there as well..), so will take a look at the gitolite setup: my impression is that it may be able to protect specific branches.

Hi Gin, thanks for your comment! Generally, no, I...

2011-11-14T14:54:06.297+01:00

Hi Gin, thanks for your comment!

Generally, no, I haven't seen any real problems with the prefix setup.

There is one tiny detail: If you accidentally push directly to the bare bare repo (instead of doing a dcommit), and you need to revert that by doing a forced push to remote/svn, you don't have any local reference any more to which commit the SVN HEAD is at. However, this is not really a problem if you are (a) careful, or (b) take measures to make the bare repo non-writable for developers.

Great, I came to a similar conclusions earlier - b...

2011-11-14T14:04:05.526+01:00

Great, I came to a similar conclusions earlier - but haven't seen it written down and forgot it in the meantime as well (so kept using update-ref to keep the two pointers refs/remotes/trunk refs/svn/trunk refs/remotes/mirror/svn/trunk in sync).

Have you run ran into any negative side-effects/gotchas with this --prefix setup since?