tfnico's blog

I was pretty happy with myself after I figured out to always use git-svn with the --prefix configuration . However, as  +Johan Herland   foretold , this stopped working after Git 1.8.3.2. Or to be precise, the convenient branch checkout/tracking mechanism stopped working. So while you could do this before (imagine a fresh git-svn clone with --prefix=mirror/ ): >git branch -a                                         * master   remotes/mirror/trunk #this is a svn remote > git checkout trunk   Branch trunk set up to track remote branch trunk from mirror. Now, after upgrading Git past Git 1.8.3.2, you'll get this instead: > git checkout trunk error: pathspec 'trunk' did not match any file(s) known to git. Even if you try doing it more explicitly: >git checkout -tb trunk mirror/trunk fatal: Cannot setup tracking information; starting point '...

TLDR: I've recently been forced back into using git-svn, and while I was at it, I noticed that git-svn generally behaves a lot better when it is initialized using the --prefix option. Frankly, I can't see any reason why you would ever want to use git-svn without --prefix.  It even added some major simplifications to my old git-svn mirror setup . Update : Some of the advantages of this solution will disappear in newer versions of Git . For example, make a standard-layout svn clone: $ git svn clone -s https://svn.company.com/repos/project-foo/ You'll get this .git/config : [svn-remote "svn"]         url = https://svn.company.com/repos/         fetch = project-foo/trunk:refs/remotes/trunk         branches = project-foo/branches/*:refs/remotes/*         tags = project-foo/tags/*:refs/remotes/tags/* And the remote branches looks like this (git branch -a):     remotes/trunk ...

Just a quick mention for you people who can't be bothered with my somewhat intricate Git-SVN mirror setup , there now is a now is a solution packed into a product: SubGit . I tried it out on a little local SVN repo recently, and it worked just fine. It delivered pretty much perfect two-way syncing/bi-directional mirror (which I've earlier deemed to be very impractical with git-svn ). The bad parts are: It's new (use at your own risk, in other words: DO NOT install it in your main-line subversion repo used by a 100 devs). It's closed source, so you're at the mercy of the SubGit devs for fixing any feature that you need in your special repository.  It requires instrumentation on the Subversion repository installation. If the repository is beyond your control (hosted externally, or by some separate department), you're stuck with my old setup . The good parts: Super-sweet functionality! I mean, bi-directional Git/SVN is highly sought after. Seems to...

This post is part of  a series on Git and Subversion . To see all the related posts, screencasts and other resources, please  click here .  So no sooner than I had done my git-svn presentation at JavaZone , I got word of a slightly different Git-SVN mirror setup that makes it a bit easier to work with: In short, my old recipe includes an annoying git update-ref step to keep the git-svn remote reference up to date with the central bare git repo. This new recipe avoids this, so we can simply use git svn dcommit   directly. So, longer version, with the details. My original recipe is laid out in five steps: Clone a fresh Git repo from Subversion. This will be our  fetching repo. Set up a  bare repo. Configure pushing from the fetching repo to bare repo In the shoes of a developer, clone the repo Set up an SVN remote in the developer's repo In the new approach, we redefine those last two steps: (See the original post for how to do the fir...

This post is part of  a series on Git and Subversion . To see all the related posts, screencasts and other resources, please  click here .  Update : I've also shared my notes from the talk.  Here they are . So, the Cisco/JavaZone folks were lightning fast and uploaded the recording of my session at JavaZone the day after I held it. Here it is: Living with Git and Subversion in Parallel from JavaZone on Vimeo . You'll have to watch it fullscreen and in HD to follow the command line action, I reckon. I think this marks the climax, and probably the end of my adventures with git+svn. I mean, we're still using it at work, and I'll still help people with it when they ask on the "Git for human beings" mailing list . However, I won't submit it to any more conferences or user group meetings. It's been a really interesting topic, and an important one. The resources-page has gotten 6000 views (plus a lot more on the blog posts), and the screencas...

So, just a quick post to announce that I did my Git+SVN talk today at GearConf . I feel that the talk went pretty well. There were only 45 minutes at hand, so I focused on setting up a Git-SVN mirror with branches and tags . I also set up Jenkins to drive the git svn fetch+git push in the fetching repo, and in the end put the bare repo on GitHub (for full buzzword compliance). If you attended the talk, I would really appreciate to hear any kind of feedback! Either comment here, or rate my talk at SpeakerRate.com . Otherwise, 1st day of the conference was great! I got an introduction to Chef from Martin Eigenbrodt , heard an eloquent Maven rant from  Halil-Cem Gürsoy , and  Michael Leibfried talked about how to introduce Scrum in hostile environments. All really interesting talks. Also speaking in the revision control department was Stefan Lay presenting the awesome upcoming EGit 1.0 release , and Martin Geisler , a fellow Scandinavian, presented Mercurial, where h...

It's that time of the year again! Well, actually last year GearConf took place in October , and this year it's June 9-10th. Well, anyhow. Again I've gathered up some premium octane Git-SVN knowledge , a bit like the stuff I did at the RuhrJUG in Essen , but this time I have to fit it into a slot smaller than one hour. At least I hope to fit in the interaction with Jenkins and GitHub this time, and do a bit less of the git-svn basics. So, if you live around the Ruhr  area, in  NRW , or otherwise nearby, get your GearConf ticket  now!

Update: There's now a Xing signup for the event:  https://www.xing.com/events/living-with-git-and-subversion-parallel-710010 I will be heading up to Essen next month to present Git+SVN at the ruhrjug event . The arrangers ( Infaktum ) are also behind GearConf , where I presented on the same topic last year . The event takes place on 14th of April, and starts at 18:00 in the Glaspavillon Campus Essen: View Larger Map If you want to know the tricks of living with Git and Subversion in parallel , be there! I'll be showing off all the steps, from getting started with git-svn, through the obligatory Git-Subversion mirror, to the final-migration-away-from-SVN. Hopefully there'll be time for showing off stuff I didn't get to at GearConf, as well as some good discussion. Oh, by the way, if you've got any reference cases where you are also using git-svn, I would love to hear about it. I recently noticed that Gnu Cash  are using it, and it would make me happy to ...

This post is part of  a series on Git and Subversion . To see all the related posts, screencasts and other resources, please  click here .  I just got an email asking me how one can set up a bi-directional Git-SVN mirror. It ended up being quite a long answer, so I'll post it here for the benefit of other Git-SVN readers with the same idea. As you may know, I'm a proponent of my own Git-SVN setup . I remember trying to go down the path of a bi-directional repository, but always ran into problems. Here is how it could work: However nice this would be to have, it can be very hard to achieve in practice: Git-svn requires working in a non-bare repository, so pushing to it is by default refused. You can work around this by doing this in the target sync repo: git config receive.denyCurrentBranch ignore You also have to automatically perform a git reset --hard in the syncing repo after each push (by some git hook?), because the work-dir is c...

A recurring problem for us Git users is that we tend to forget the good old Subversion tricks. We want to do some patch on some old code in a Subversion repo, and suddenly we've got no idea how to work around. Here's a quick guide: > git pull > svn update > git add new_file svn add new_file > git add changed_file N/A: SVN automatically adds all modifications to the index. If you don't want to commit it, don't change it. > git commit; git push (you always have to do these together): > svn commit > git revert [SHA] > svn merge -c -[R] . > git branch branch_name > svn copy url_to_project/trunk url_to_project/branches/branch_name > git tag tag_name > svn copy url_to_project/trunk url_to_project/tags/tag_name > git checkout branch_name > svn switch url_to_project/branches/branch_name/ > git merge branch  svn merge -r[start]:[end] url_to_project/branches/branch_name . (Note that you have to keep track ...

This post is part of  a series on Git and Subversion . To see all the related posts, screencasts and other resources, please  click here .  This extends the posts where I explained how to set up a git-svn mirror for a single directory. NOTE: If you just want to use Git against a SVN repo on your own, stop reading ,now, and stick to the git-svn basics. However, if you want a setup where you can share a Git repository with colleagues and friends while still interfacing with Subversion, keep reading. I'll show how to set up a git-svn mirror for a standard Subversion project with trunk , branches and tags . It's a bit like the single directory mirror, but in order to keep all branches in sync, it's a bit more fiddling. The good part is that this setup enables us to cherry-pick commits from one branch to the other. This is slightly smoother than using svn merge . First of all, let's repeat how our Subversion and Git-repositories look physically (roughly the sa...

This post is part of a series on Git and Subversion . To see all the related posts, screencasts and other resources, please click here . This is my last Git+SVN screencast for the time being. Appropriately, it's about the steps we can take when leaving Subversion behind forever, allowing us to fully make use of Git. We are yet to do this at our place. We will still maintain the Git+SVN bridge until the majority of the developers have been persuaded into using Git as an "SVN client". And in case Mercurial starts to show off some more impressive SVN-integration , we might drop Git in favor of that. Credit to Thomas Rast who helped me out on the #git IRC channel some time ago. This article of his covers the technicalities of the last screencasts much better than I could explain in the video. All videos can be viewed on this YouTube playlist , and all content is linked together on my Git+SVN page on tfnico.com . Thanks for watching!

This post is part of a series on Git and Subversion . To see all the related posts, screencasts and other resources, please click here . Time to whip out the last two screencasts for this round. Here's the first of the two, hopefully the second one will be out later this evening. Depending on the complexity of the history of your own Subversion projects, undertaking this kind of "archeology" might seem intimidating. At work, we have a rather large SVN project which has been thrown around different locations, split into 30 projects, merged back together again, and moved again on a regular basis. I once began digging through this to get all history into Git, but gave up after two modules. It simply wasn't worth it before we're ready to do a complete migration (leaving SVN behind, which is the topic of the next screencast).  So, for now, I haven't got the *entire* SVN history in the Git repository. But it doesn't matter, I can still work productively...

This post is part of  a series on Git and Subversion . To see all the related posts, screencasts and other resources, please  click here .  Another episode on how to live with Git and Subversion in parallel: Only a few days left till GearConf, where I will be repeating the exercise, adding all sorts of useful hints and tips on the way. NOTE : At the end of the cast, I presented this little shell-script that I normally use for committing: #! git update-ref refs/remotes/git-svn refs/remotes/origin/master git svn dcommit Some more background: git svn dcommit actually updates the refs/remotes/git-svn However, in the case that I first do a git pull from the bare repo, getting the new commits via the "pure" git command, no svn refs are updated! Example: Let's say bob commits a change. John then updates his repo: tfnico@flint:~/john/website/> git pull --rebase remote: Counting objects: 8, done. remote: Compressing objects: 100% (4/4), done. remote: ...

This post is part of  a series on Git and Subversion . To see all the related posts, screencasts and other resources, please  click here .  This one explains some more of the physics of syncing repositories between Git and Subversion land.  The big morale is that you can't really work with branches the way they were made in Git. History will have to be linear by the time you want to push back to Subversion, if you don't want to lose history. This basically requires every merge operation to be a rebase instead. Theoretically, you could do branches between Git collaborators, but it's probably best to not stay so long out in Git before pushing changes back to Subversion, anyway, so the case for doing any useful branches are basically lost. You can still do local branching for experimenting with some wild refactoring, or just for sorting different working sets of your code (I do this a lot, in fact). But as long as it's going back to Subversion, it'll have to b...

This post is part of  a series on Git and Subversion . To see all the related posts, screencasts and other resources, please  click here .  In preparations for presenting "Living with Git and Subversion in parallel" at GearConf  in a few weeks, I've been practicing a Git+SVN exercise, going through all the steps from Git-cloning a Subversion repo, to full centralized Git-SVN mirror. While I was doing this, I figured I might as well make some more use of this, and record some screencasts as I go along. I've just posted the first three on YouTube , and collected all my various works on Git and Subversion on this page . Feedback is much appreciated! Update: I'll try embedding the videos here on the blog too: Git+SVN #1: Cloning a repo Git+SVN #2: Some commits back and forth Git+SVN #3: Conflicts

After tirelessly blogging about how to work with Git and Subversion in parallel for some time now, I fired off an abstract to GearConf , as this looked like a subject that would be right up their alley (they had talks about Git and Mercurial last year). They accepted the talk a couple of days ago, so it looks like I'll be driving up to Düsseldorf on the 11-12. October. Interestingly enough, GearConf is sharing the event with the Atlassian Software Conference Düsseldorf ,.  I've been up close and personal with their products before , so it'll be cool to see how far they've gotten since back in the day (when their products were already awesome). For anyone in the area, the people behind GearConf are also arranging  WebAppDays  in Düsseldorf from 27-28. September. I would go there too, but I think I'm all out of conf-days for this year :)

This post is part of  a series on Git and Subversion . To see all the related posts, screencasts and other resources, please  click here .  This post is part of a (slightly chaotic) series on Git + Subversion. Unfortunately, due to my problem with editing posts in Blogger, they've ended up a bit scattered and poorly organized. So here's a summary of the posts with more fitting titles: A big rough introduction to distributed source control and Git Why and how clone of a Subversion repo into a Git repo  (aka SVN mirror) Sharing a Git SVN mirror in a team Sharing a Git SVN mirror in a team clarifications So, if you just want to get into using Git, take a look at 1. If you want to port an existing Subversion repo, 2nd post is the thing. The 3rd and 4th are for those of you who need to stick with Subversion for a while longer. The illustration below illustrates an example workflow for the last case. Ref GitFaq . Note that devs *might* have to run update-refs ...

This post is part of  a series on Git and Subversion . To see all the related posts, screencasts and other resources, please  click here .  I'm afraid I exaggerated in my previous   posts , and given the impression that living with Git and Subversion in parallel is easy. I would update it, but Blogger is refusing to edit the post without screwing it up. So here it is in clear text: Be prepared to face some major constraints in using Git against a Subversion repo, compared to how it using Git standalone. The manual says it best: The git svn tools are useful if you’re stuck with a Subversion server for now or are otherwise in a development environment that necessitates running a Subversion server. You should consider it crippled Git, however, or you’ll hit issues in translation that may confuse you and your collaborators. To stay out of trouble, try to follow these guidelines: Keep a linear Git history that doesn’t contain merge commits made by git merge. Rebas...

This post is part of  a series on Git and Subversion . To see all the related posts, screencasts and other resources, please  click here .  This is a follow-up to the previous post on how to live with Git and Suversion in parallel . It's really trivial stuff for any experienced user, but was worth noting down somewhere for my own sake. I've cloned a project called "fudge" from Subversion: >git svn clone https://scm.mycompany.com/svn/fudge So my local repo has the correct svn-remote configuration and all that to go with it inside fudge/.git/svn . This is done automatically when you svn-clone. The bad thing is that all my Git-mates at work have to wait for me doing svn-rebase before they can pull the latest code from Subversion from my repo into theirs. I want to get rid of this responsibility. I'll put something similar to my svn-rebasing repository on a server, have it run svn-rebase regularly, and push the changes to a centralized git repository, ...