The mirror man says
Federico wrote a nice post about Git. I just wanted to add a few things to it really.
- If anyone wants to buy me beer for Bazaar mirror, Git mirror, or the Mercurial mirror that people are begging me for then please remember… Spirits, spirits, spirits. (They are especially good at making me forget, which is handy after setting up something like git mirror
The stronger the better!) - git-mirror.gnome.org does not make git.gnome.org any easier. It just makes it easier to try out git-svn on a GNOME project. (Some/all of these may be fixable with surgery, but the one way conversions will likely be quicker anyway).
- The main reason is of course the polluted logs (filled with git-svn rev id metadata). I would resist any module having a Git repo with such ickyness in its history.
- I didn’t have the data to provide git-svn with an authors lookup
- What to do about the references to svn in git-mirror? All the branches have an svn/ prefix…
- git-mirror ignores Bazaar metadata. Thats right folks, it says svn.gnome.org on the tin but the Bazaar users have already started upgrading GNOME to Bazaar with bzr-svn. Check out this. You’ll notice how commits made with Bazaar are somehow “better” than their SVN counterparts. When I apply someones patch with bzr-svn I log who it is from using the –author property. I want this preserved.
- The git mirroring process uncovered bugs in git-svn, despite its heavy use by the core GNOME hackers. Even one on GTK+, which is meant to be the thing that everyone makes a mirror of! So we will likely break other git import tools too. This is true of any DVCS, so my point is really “its never going to be ‘easy’ to ditch SVN”.
Lets show a bit of even handedness and community and not make choosing $DVCS like chosing $EDITOR. Git people, please try out bzr-mirror. Especially merging and branching stuff. Unlike git-svn, you can use bzr-svn as though its a normal, full blown DVCS. Blog about your experiences, let the Bazaar developers what they need to work on. (I will spit my vodka in your eyes if all you come up with is speed). Likewise, the Bazaar folks should try out git-mirror and see if its as good as they say, and tell them which bits of the UI need fixing. What do you find yourself missing?
Mercurial people: Take me to your documentation! What is the standard way to make a Mercurial “mirror” of SVN?
In the next few days I should be taking the lid off a loggerhead instance for bzr-mirror. Of interest is the search, which uses a full text index created by the wonderful bzr-search plugin. It’s pretty impressive.
June 26th, 2008 at 1:43 am
Why do you call the git-svn rev id “pollution”? It’s part of the history. It makes sense to keep. It certainly doesn’t hurt to have it.
I am also not sure why the bzr meta data matters in any way. Also, the only difference I could notice is the names that are resolved?
June 26th, 2008 at 4:20 am
In what way does the UI of bzr-svn and git-svn matter? They’re both stop-gaps.
June 26th, 2008 at 7:35 am
Jason: Bzr-svn works almost the same as Bzr, just git-svn that has a very different workmethod (from what I hear about it).
Even then, the purpose is to have people try out a DVCS.
June 26th, 2008 at 8:25 am
@Jason:
They are very important, IMO anway, stop gaps as they are often introductions to the DVCSs. Almost all projects I work on are CVS or SVN primarily so my exposure to DVCSs in real working cases are via {git,bzr}-svn, etc.
Because we’re often evaluating and learning DVCSs via interaction with SVN repos these days the UI does matter quite a bit. For instance, generally use git-svn rebase is encouraged, but git rebase is not. With bzr-svn you’re basically using the same commands you would with a normal bzr branch.
@John Carr
I’d love to see a Mercurial mirror (even though I know it’s a lot of work) as I’m leaning towards that way as a preferred DVCS. However, I haven’t yet figured out the best way of mirroring SVN with Mercurial. It’s my only real gripe with hg that interaction with SVN and CVS is not very mature. Right now I’m using hgsvn which provide hgimportsvn and hgpullsvn commands.
June 26th, 2008 at 9:47 am
blah:
there really is no point keeping the git-svn metadata around - we didn’t keep any kind of meta data around for the mapping cvs commits to svn commits, and it didn’t hurt, so why do it now? and yes, it is messy. I don’t want or need to see that information as a developer.
June 26th, 2008 at 4:00 pm
Go and ask for help in #mercurial (freenode).
I guess they’ll be very happy to help out!