How to prevent Subversion from merging binary files?

+1 A:

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.

Sander Rijken 2009-06-05 22:02:39

I would rather keep this on topic - how to prevent conflicted binaries

Mario 2009-06-08 18:04:46

Not versioning build output when there's no need is a great way to prevent conflicted binaries.You cannot prevent conflicts if both your copy and the copy on the server have changed.

Sander Rijken 2009-06-08 21:41:20

+1 A:

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.

bluebrother 2009-06-05 22:08:46

Tagging the source should be enough to recreate the binaries. Archiving binaries isn't a task for source control.

Sander Rijken 2009-06-05 22:12:25

While I completely agree with this companies / managers seem to think differently. At least from my experience, hence the comment.

bluebrother 2009-06-05 22:17:21

You might not want to recompile core libraries very often. So in those cases I think it makes sense to put dlls in svn.

Ryu 2009-06-05 23:15:24

This doesn't answer my question - I have the need to put binaries in svn without making a tag or trunk. This also doesn't explain why sometimes they wouldn't conflict and just get replaced, but other times they do conflict. Any more ideas?

Mario 2009-06-09 18:41:56

Maybe you should explain *why* you have a need to put binaries in trunk. That way it might be possible to find other solutions for your issue. If you frequently get conflicts with the binaries your storage model seems to be unsuited for your problem.As for the other question: if there are no conflicts (i.e. both files are identical on a binary level) they get replaced. If you rebuild the dll and the result is exactly the same as the file in svn you won't get a conflict when the file is updated in svn (as it was only changed at one location).

bluebrother 2009-06-09 22:35:17

A:

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.

Niki Yoshiuchi 2009-06-05 22:08:47

Since they are binary files I would want svn to update them, that's it. No conflicts, no trying to merge - nothing. Just replace it with the newest one.

Mario 2009-06-05 22:23:35

Well in that case you might be able to write a pre-commit hook-script that checks for a conflict and if it finds one, resolves it using the more recent file.Unfortunately I have never written a hook-script so I can't be of much help there.

Niki Yoshiuchi 2009-06-05 22:34:01

A pre-commit hook-script cannot fix this, because this is a server-side script. The conflicts and merging happen when updating on the client.

Sander Rijken 2009-06-08 21:42:47

+2 A:

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.

2009-07-29 11:43:52

The files never change in the repository, they obviously change from a client updating that file in the repository. Since they are binary (for instance a word document or diagram) they should NEVER be merged, just replaced. Maybe I described this problem wrong but all I want to be able to do is have svn never try to merge and just get the newest version on binary files

Mario 2009-08-03 17:01:53

That's exactly what this answer describes; the --accept theirs-full throws away any local changes when there are incoming changes. This means that if you have a modified Word document, and someone else changed it, and you svn update --accept theirs-full, your version is lost, and updated with the one from your colleague

Sander Rijken 2009-08-03 21:02:43

A:

I can signal a similar problem: im my case the file is a text file, but the property svn:mime-type application/octet-stream has been set on it, BECAUSE WE CANNOT ACCEPT AUTOMATIC MERGES. During an update phase, the file has been declared MERGED!. We use Subversion 1.6.2 and TortoiseSVN 1.6.6

Has someone experienced similar problems and found a solution or at least a reason? Thanks in advance.

elena villani 2009-12-02 08:44:25

I still haven't found a solution - this problem is really annoying :(

Mario 2009-12-03 18:00:13

I have just encountered this with one of our developers who didn't have our company svn config file pushed to his machine. His UTF-16 files he added were auto-detected as application/octet-stream. Using Tortoise 1.6.8 and a 1.6.x server, there was an update done before commit and the two files merged -- incorrectly.Glad I'm not the only one that has found this bug.

Dan 2010-06-24 02:38:30

ansaurus

tags:

views:

answers:

How to prevent Subversion from merging binary files?

related questions