SVN ignores file extension .so by default – which corrupted my build

I was just working on my current OSGI project which is build with Eclipse PDE headless for multiple platforms.
The Eclipse Deltapack contains a launcher bundle (directory) called org.eclipse.equinox.Lauscher.gtk.linux.x86_1.0.200.v20090520 which contains a file called
This launcher bundle I also committed to my SVN repository for my headless build from the build machine.

I was wondering why my build was always broken and corrupt and I found out that in my SVN repository the file was missing…and indeed it was NOT committed.
I first thought I made a mistake, so I removed and recommitted everything. And again, the wasn’t there.

So I started googling and I found this which directed me to this. Apparently *.so files are igored by SVN by default even though there is no svn:ignore property set.

In order to solve this I did the following:

  1. Open the file ~/.subversion/config
  2. Remove the comment from the line which starts with # global-ignores
  3. The line looks like this now: global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store

As you can see the .so file extension is not defined anymore and suddenly .so files also show up in my SVN Commit Dialog (I am using svnX on MaxOSX).

This also explains a bit my most recent issue I was having with a broken Eclipse build.

I am not too sure if this is a good default by SVN to ignore .so files as those are shared objects in Unix Environments which are important for Multi Platform builds in my case. Anyway I found this out and solved the problem.

Dieser Beitrag wurde unter Software-Development abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

11 Antworten auf SVN ignores file extension .so by default – which corrupted my build

  1. frlan sagt:

    Beside of that subversion is trying to think for the user, an .so shouldn’t be put into a VCS IMHO.

  2. Christoph sagt:

    Maybe normally you shouldn’t put that, but in the case I described, it is important that this file is there. if you are versioning 3rd party libs in your svn as it was the case here, then those 3rd party libs should not be corrupted just because I have put them into SVN.

  3. thanks for very interesting article. reg.

  4. Jase sagt:

    Thanks, this was killing me. I need so add .so files to an svn repository which manages puppet for sys admin tasks, and I need .so files to be present.

  5. I found similar SVN problems at work… I think SVN shouldn’t think for the user as this will eventually leads to just more problems… I could have a project in which „.so“ is my custom file extension for my custom binary data (maybe SerializedObject file data :)). Now I definitely want SVN to put that files in my repo, period.

  6. F*ckin‘ tremendous things here. I’m very satisfied to look your post. Thanks a lot and i’m looking ahead to touch you. Will you kindly drop me a mail?

  7. Dawson sagt:

    Simply wish to say your article is as surprising. The clearness to your post is simply cool and i can think you’re an expert in this subject. Fine along with your permission allow me to grab your feed to stay up to date with approaching post. Thanks one million and please continue the enjoyable work.|

  8. Hallo! Ich erstelle gerade ne Seite zum Thema Online Dating Tipps und Tinder und Lovoo. Freue mich über Besuch!

  9. BETRAKON sagt:

    Irgendwie ist das scrollen hier so langsam auf meinem Macbook…

  10. It’s blogs like this that make a Difference, Keep up the good Content.

  11. owzleee sagt:

    you can also use –no-ignore on the command line for a one-off import

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.