Apple hasn’t been any more specific about its plans for the facility, which one expert called “big-ass.”

Apple hasn’t been any more specific about its plans for the facility, which one expert called “big-ass.”

—Chris Foresman, for Ars Technica

How to merge Subversion branches with Git

Git-svn is good. It’s really good. As others have said, it’s actually too good, in that it reinforces the status quo (of continuing to use a Subversion repository regardless of the inherent issues) and the process of merging exemplifies this in a particularly insidious way.

It happens to many Git users that they are eventually forced to work with a Subversion repository. Fine, they’ll say, no problem. Just use Git-svn and you can do just about anything like you normally would in Git. Pushing to the repository will take longer, but oh well.

Then someone has to merge something.

Subversion users hate merging. It’s slow, it’s difficult, things go wrong and they have no idea why. They can read the docs cover to cover, they can Google it for hours, but they will never find out how to make it work right. They blame themselves, because it’s supposed to work, but they don’t know what to do. It’s just painful and they’ve resigned themselves to that fact.

But then you come along, and you have Git-svn. All other interoperation between Git and svn works so flawlessly, you just assume merging should work as well. So you do the merge in Git, it takes under a second and it looks like it worked fine. Problem solved?

Unfortunately, you probably never read the ‘caveats’ section in ‘git help svn’. Go ahead and read that now.
(Tip: git help -w svn)

But maybe you didn’t read it, or maybe you shrug and say, ‘eh, it seemed to work fine’, and you go ahead and ‘git svn dcommit’ the merge.

Basically: Git-svn supports reading Subversion merge metadata, but doesn’t support writing it. If you ‘git svn dcommit’ that merge, the Subversion server will receive all of the file changes but nothing to indicate it’s a merge. It will look like you made those changes all by yourself, in one commit. And of course, Subversion doesn’t support Git’s merge metadata either, so this isn’t even preserved for future Git-svn clones of the repository.

The result of this:

If you do a Git merge of Subversion repositories, you are the only one who can ever see that merge again.

(And even then, only if you keep that working copy of yours preserved forever). All other Subversion users and all other Git-svn users will not see this as a merge. And because of this, you have made future merges, annotations, history tracking, and many other things much more difficult for everyone else, whether they use Subversion or Git-svn. (In particular, it may make future merges with Subversion on that branch nearly impossible.)

This is why the safest thing to do, and what I always recommend to Git-svn users, is:

Never merge Subversion branches with Git.

Switch back to Subversion when you need to merge Subversion branches. Yes, it’s slow, painful and error-prone. This is your motivation to convince the organisation to switch to a sane SCM (remember, as much as Git seems like the best one, there are several alternatives that, if not as good as Git, would at least be an improvement). You can only do so much to work around a system that is fundamentally broken. If your organisation seems incapable of understanding this, it may be an indication that that organisation is also fundamentally broken, and you may wish to consider how much you can do to work around that.

However…

If you’re not going to heed my warning, and you’re determined to do it anyway, here’s how to do it while keeping the level of destruction you cause to a minimum.

Assume you’re merging a branch named ‘source’ into a branch named ‘target’. Open two Terminal windows (or tabs, whatever): one for Git, one for svn. The part before the $ indicates the line number and which Terminal you should type into.

It should go without saying that if you receive errors at any point (not counting conflicts, which you should resolve normally), and you don’t understand what’s going on, you should abort the process, undo whatever destruction you have caused and start over.

[01:git]$ git checkout target
[02:svn]$ svn checkout proto://url/to/target target
[03:svn]$ cd target
[04:git]$ git svn fetch
[05:git]$ git svn rebase -l
[06:git]$ git merge remotes/source # (resolve any conflicts)
[07:git]$ git commit --amend -m "Merge source - PARTIAL"
[08:git]$ git svn fetch # IF THE RESULT of this is that you received more commits, GOTO line 05
[09:git]$ git svn dcommit
[10:svn]$ svn up # IF THE RESULT of this is that you received more commits OTHER THAN YOUR MERGE(s), GOTO line 04
[11:svn]$ svn merge proto://url/to/source --record-only
[12:svn]$ svn commit -m "Merge source - COMPLETE"

The key here is the ’–record-only’ option to ‘svn merge’, which only sets the metadata and does nothing else. This should effectively repair the missing metadata caused by your Git-svn merge.

As you can see, this is a rather ridiculous amount of effort to do a merge. What’s more ridiculous, though, is that it may end up being drastically less time and effort than doing the merge with Subversion, due to all of the nonsensical conflicts that Subversion introduces, and/or simply the amount of time Subversion takes to do anything (I have literally sat watching Subversion churn through a merge of a few large commits for 30+ minutes, when Git did the same thing in less than one second).

The risk here (besides the possibility of you doing a step wrong), and the reason for all of the GOTOs, is that your merge is split across several commits, and while you’re committing them, other users may still be using the repository (especially while line 09 is executing, which can take a while). If the merge content from Git and the merge metadata from svn don’t agree, you have a big problem that will cause a lot of trouble for you. If possible, it is advisable to ask other users to stop committing while you’re doing this. If it is not possible to ask this, or if doing so would draw you ire, and indeed if you’re working with a high-traffic repository, my solution may be essentially impossible for you to complete (infinite loop).

An odd side effect that you may notice: your Git working copy will show the merge as having occurred at your first commit, but other Git-svn clones or Subversion clients will show it as having occurred at your last commit. This is probably a minor issue.

One last word of advice: Avoid doing people too many favours by doing their merges for them. You could end up becoming a de-facto Release Engineer, and that’s not a fun job.

Analysis of World of Goo’s iPad Launch by its creators

Analysis of World of Goo’s iPad Launch by its creators

An interesting look at the differences between iOS App Store and more traditional game software markets.

I believe that if you identify with any political group or philosophy that has a name, you are far more susceptible to confirmation bias than someone who doesn’t. And as a general rule, I don’t trust anyone with a strong opinion on a complicated topic.

I believe that if you identify with any political group or philosophy that has a name, you are far more susceptible to confirmation bias than someone who doesn’t. And as a general rule, I don’t trust anyone with a strong opinion on a complicated topic.

—Scott Adams

Thieves stealing debit card numbers via fake bank door locks

Thieves stealing debit card numbers via fake bank door locks

This is why I always swipe a card that isn’t a credit or debit card, such as a grocery store discount card, to open the bank door. I’ve tried this with dozens of branches of different banks over the years and it’s never failed to open the door.

I read about this trick on the internet many years ago (don’t remember where): the door lock doesn’t actually verify the authenticity of the card; it only checks that it has a readable magnetic strip. It doesn’t matter what kind of card it is. The door lock is only there to make you feel safer, or maybe to keep homeless people out; it doesn’t do anything to verify that you’re a customer of that bank.

A fake door lock could, however, steal the number you just swiped. This would be easy to plant since they’re often in a low-traffic, easily accessible location. But I’m not too worried about thieves stealing my discounts at the grocery store.

(via Schneier)

Adium's attempts to be in the Mac App Store

Adium’s attempts to be in the Mac App Store

Not going so well.

WikiLeaks is not the problem

WikiLeaks is not the problem

Bruce Schneier:

In the 1970s he would have mailed them to a newspaper. Today he uses WikiLeaks. Tomorrow he will have his choice of a dozen similar websites.

Schneier on Security: TSA Backscatter X-ray Backlash

Schneier on Security: TSA Backscatter X-ray Backlash

Good collection of links to what people are saying about the TSA lately. It’s good to see that this is getting so much attention.

saw this when i was reading this article im

Saw this when I was reading this article.

I’m sorry too, Adobe. I’m sorry it didn’t work out. But, look, we both just have to move on, okay?

this is the dialog you get when you dont have

This is the dialog you get when you don’t have Flash installed on Mac OS X, and you click¹ the ‘Missing Plug-In’ text on a page that has a Flash applet.

I assumed it would link you to the page where you can download Flash, but no. Just in case it wasn’t perfectly clear, Apple really doesn’t like Flash and isn’t going to help you install it.

1. Note that this dialog does not appear automatically when the page loads. It used to. ↩︎