CODEWITHSUNDEEP
svnversion-control
Mario
Mario

Reputation: 3445

How to prevent Subversion from merging binary files?

We have the need to keep .dlls in our repository. Our team experiences SVN conflicts on .dll files quite frequently and it is super annoying. For some reason, even though the mime type of the .dlls are set to application/octet-stream, svn is still trying to merge them.

From what I found here (which I swear the way things used to be) it says that as long as the mime type isn't text, svn will not try to merge them. But looking at my dlls tells me that svn is merging my application/octet-stream files too (at least I am assuming SVN is merging, not sure why there would be a conflict without a merge). Why the heck would svn try to merge a binary file? It's just stupid...

Anyone come across this problem?

My aim is to find a solution that allows binary files to be part of the repository, but never be conflicted. I want SVN to just replace with the newest binary and call it good.

Please don't discuss why I should or should not be putting binary files in the repository - I have to and don't want conflict problems.

As a FYI: I use both Tortoise 1.5.0 and Ankh.

Upvotes: 3

Views: 5587

Answers (5)

Bret
Bret

Reputation: 11

We have the same problem with certain files.

CVS handles this problem very well, but unfortunately my company is moving to Subversion.

Certain config files are modified by our app everytime you run it, but when the developers check in new changes, we want them to always overite the users repository.

In the .CVSwrappers file, put *.fileext -k b -m COPY. This tells CVS to always make a backup copy of the file in the local repository and download the new version when there are conflicts. So elegant.

There is no equivalent setup for SVN. If anyone knows how, please post it.

Upvotes: 1

Reinder
Reinder

Reputation:

To make sure that I understand you correctly, let's recapitulate:

  • you have binary files checked into svn
  • these files can change both client-side and in the repository
  • whenever both are changed, the changes from the repository should 'win'

AFAIK, the svn way to do that would be:

  • run 'svn update --accept theirs-full' on the binary files
  • run a regular 'svn update' on the whole local copy

I do not think this can be done in one command, and I also do not think it should be doable in one command, as that first command can lose valuable data.

Upvotes: 3

Niki Yoshiuchi
Niki Yoshiuchi

Reputation: 17561

Are you sure that it's trying to merge them? It sounds more like you are getting a conflict because subversion doesn't know how to merge them (which you don't want it to do anyway).

What exactly do you want to happen if you have a locally modified dll and someone commits the same dll before you do? What do you expect to happen? This is obviously a conflict and subversion doesn't know if you want it to use your dll or their dll.

Upvotes: 1

bluebrother
bluebrother

Reputation: 8886

If the file was changed on the server and locally you'll obviously get a conflict. Of course updating the working copy includes updating the binary files as they are part of the revisions. This doesn't mean svn tries to merge them, but you'll definitely get a conflict. If those files are changed frequently I guess they are generated frequently -- possibly even compiler output files. Such files should not be in the repository at all.

If you need to archive release binaries (or similar) you should do this on a tag or release branch but not on trunk.

Upvotes: 1

Sander Rijken
Sander Rijken

Reputation: 21615

These dll files, are they build output from the actual projects?

If that's the case, they shouldn't be put in svn at all. Subversion should contain the source files, and a build server / dev box can build the dlls from there.

Upvotes: -1

Related Questions