How to turn-off skipping of .a files during svn add

Question

This question is similar to others I've seen on SO, but not quite the same. The other similar questions either couldn't add a .a file (I can add it explicitly) or they had global-ignore problems (I don't think I do.)

THIS question is about how to change the default svn behaviour that doesn't appear to be caused by global-ignores (that I can tell.) Here's a typical failure mode:

• I want to add a 3rd party library (such as Flurry), so I do svn add 3rdParty/flurry
• svn shows a bunch of files added. I don't notice that it decided not to add libFlurry.a.
• I commit.
• My client can't build, because they're missing the .a file
• I go back and svn add 3rdParty/flurry/libFlurry.a, and commit, which works as expected
• All is fine at the client end.

What's weird is, I don't have any global-ignores set. Here's a snippet from my ~/.subversion/config file:

### Section for configuring miscelleneous Subversion options.
# [miscellany]
### Set global-ignores to a set of whitespace-delimited globs
### which Subversion will ignore in its 'status' output.
# global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store

note that global-ignores is (a) commented out and (b) doesn't contain *.a, anyway.

At the start of the project, I did an svn propset svn:ignore -F with a file that contained:

### General
build
bin
*.pbxuser
*.mode1v3
*.class
jars
Logs
logs
xcuserdata
*.xcuserdatad

### Extra
referenceMaterial
tmp
crashlogs
symbols-xxx

### AppEngine
.metadata
.settings
RemoteSystemsTempFiles
appengine-generated

### 3rd party
MP1.1

so that doesn't seem to be the cause.

EDIT: I'm on Mac OS-X (10.8.latest) and svn 1.8.1, though things have been like this for as long as I can remember.

My question is this: how can I make it so that, when I do svn add somedirectory, the .a files get taken along for the ride?

Thanks!

Answer 1

If you don't have your global ignores set, it will default to *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo *.rej *~ #*# .#* .*.swp .DS_Store. If you want to override this default, you will need to set global-ignore yourself.

Now is this a good idea: No.

You do not want to add compiled code that's machine specific to your repository. Imagine if someone who is on a Linux system wants to compile your code. The *.a libraries aren't compatible with Linux. In fact, if you update your OS, these libraries may no longer be compatible with your Mac. You're basically creating a build process that's bound to fail.

You're better off handling this in your Makefile. If these are standard libraries, you want to make sure your -L is set correctly to find these libraries. Or, you can setup your Makefile to build these libraries specifically for your system. If you need to, let the Makefile download the library project from Subversion, build the libraries, and copy them over for you to use them.

Another possibility is to setup a release server to store these libraries based upon the machine, the OS, and the revision you need. This way, you're pulling down the correct versions. This may be the only way of doing this if these are third party precompiled libraries. You can use sftp or wget to pull of these libraries as part of your build process.