resolving svn binary conflicts

Question

I use svn for a project im working on with a couple of other developers. Svn works fine for source control however we are all ways getting conflicts when we commit the dlls.

When i do i resolve the conflict (which deletes my dlls as the diff program cant handle binary files) then have to rebuild to commit. How are you meant to resolve conflicts like this?

Edit:

The dlls are in a separate svn folder as the project is a game mod and non programmers need access to the latest builds.

Answer 1

As mentioned in other answers here: you shouldn't version your generated dlls in the first place. But if you really have to version them, then you can resolve a conflict without using a diff tool which removes your dll files:

For every conflicted file, Subversion places three extra unversioned files in your working copy:

filename.mine

This is your file as it existed in your working copy before you updated your working copy—that is, without conflict markers. This file has only your latest changes in it. (If Subversion considers the file to be unmergeable, the .mine file isn't created, since it would be identical to the working file.)

filename.rOLDREV

This is the file that was the BASE revision before you updated your working copy. That is, the file that you checked out before you made your latest edits.

filename.rNEWREV

This is the file that your Subversion client just received from the server when you updated your working copy. This file corresponds to the HEAD revision of the repository.

Here OLDREV is the revision number of the file in your .svn directory, and NEWREV is the revision number of the repository HEAD.

Now, to resolve such a conflict, remove the additional files you don't want:

• if you want to keep your own dll, delete the files filename.rOLDREV, filename.rNEWREV
• if you want to keep the dll from the repository, delete the files filename.rOLDREV and filename.mine, then copy filename.rNEWREV to filename

after that, execute

svn resolved filename

to tell Subversion that you resolved the conflict yourself.

Answer 2

If it's a DLL that you are BUILDING (rather than an external one you have no source for) then the source should be in source control, not the binary.

If you don't want to include it in that particular repository then you can include it as an svn:external.

Answer 3

Generally, you wouldn't store your own compiled DLLs in source control at all. Do you have a specific reason that you need to do this?

I set up my development environments so that anybody can build any of my project components independently of anybody else. In this way, the only thing that is in my source control system is my source code. This has a number of benefits:

• It avoids binary file conflicts when trying to check in DLLs or EXEs
• The volume of data tracked by your source control system is much smaller, making it faster
• When developers always build their own DLLs, then they can be reasonably sure that the source code they have matches the compiled file. If you're using something that somebody else built, then you can never be sure.

As mentioned in the comments, it can be perfectly reasonable to store third party DLLs in your source control system, particularly if you don't actually have the source for them. I've also worked on projects where we stored distribution files (.tar.gz etc) for various open source libraries in source control, then had a whole system of Makefiles that built those libraries as part of a build-everything target.

Answer 4

For binary files, most of the time, you want to accept either version of it. For example, if the file in question is an executable tool, then typically one version might be newer than the other, and that may be the one you want to use.

To accept the version that is in the branch you are merging from, use:

svn resolve --accept=theirs-full path/to/filename

To accept the version that was previously in the current branch, use:

svn resolve --accept=mine-full path/to/filename

Sometimes, SVN will refuse to use theirs-full with a warning:

svn: warning: W195024: Inapplicable conflict resolution option given for conflicted path

because SVN is a piece of shit when it comes to merging. In that case, you have to copy files manually like in the accepted answer https://stackoverflow.com/a/410767/2279059, rather than using command-line options that are intended for what you are trying to do. If you know both files are identical (but SVN is still marking them as conflict for reasons already stated), you can also use

svn resolve --accept=working path/to/filename

While this, in the case of identical files, is effectively the same as all other commands, SVN will not cowardly refuse to execute it. Does this make sense? No, it doesn't. Deal with it.

Answer 5

It is reasonable to also have binaries in version control:

• It avoids the hassle of rebuilding for people who only use the binary.

• The binary is nailed down when you release.

To make this work the binary needs to always correspond to the sources. So if you have merged sources you need to rebuild the binary from them, picking one of the binaries from the merged versions won't do.

Answer 6

Make sure your dlls have the svn:mime-type property set to application/octet-stream or some other non-text type.

svn propget *.dll
svn propset svn:mime-type application/octet-stream *.dll

You will still have to actually resolve conflicts when they occur.

And check the File Content Type chapter of the documentation.

Answer 7

So if you have the *.dlls in a separate folder its much easier to do as follows:

1. Directly before you build your change update your *.dll folder better also update your sources, if you trust, that your colleagues only commit compilable source code. (in case of conflict (what would be your fault at that point, as you changed something before you updated to latest revision))
2. Do your build.
3. Directly commit the outcome.

Alternatively:

do not build to the path in the directory, build to somewhere outside, until you're are happy with whatever is the outcome.

Then proceed as follows:

1. Update your working copy of the dlls folder (if there is any conflict its your fault and solve the conflict by "keep theirs")
2. Copy your working .dlls to the working copy
3. Inform your colleagues that you will commit a new revision (you can let this step away)
4. Commit your work if there is any conflict it should be their fault.

You have two possibilities now:

5a. You're a very detestable person and solve the problem by keeping mine.

5b. You work as you should work... Read the log file and find out who also committed during the short time you needed to copy your work to the folder and pressed commit. Speak to that colleague. Agree on further course of action.