tags:

views:

618

answers:

5

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.

+2  A: 

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.

Greg Hewgill
I think it's fine and normal to include DLLs in source control - but only those of third party libraries, not your own source code. For instance, I include the NUnit binary in source control rather than putting the source code in there and recompiling that every time.
Jon Skeet
"all ways getting conflicts when we commit the dlls." I don't think he means third party libraries. You shouldn't commit 3rd parties all the time... Much less get conflicts.
Martinho Fernandes
@Martinho: Sure. I'm only taking issue with the statement of "Generally you wouldn't store DLLs in source control at all." I think it would be good for Greg to clarify that a bit.
Jon Skeet
@Jon Skeet: I updated my answer to clarify what I meant. And of course, my answer was in the context of how I interpreted the original question (where "the dlls" meant "the binaries I just built").
Greg Hewgill
+7  A: 

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.

Steven Robbins
I have binaries that I have to reference in some of my repositories. They usually don't change much and I typically share them among several projects so I just use an external repository for them.
Dana Robinson
+3  A: 

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.

Stefan
I think this is what im after (will have to give it ago next time) as i didnt know if you could delete the one you didnt want with out it breaking svn
Lodle
you cannot "break svn" with the tools the svn client gives you. at the most you can bring chaos into your source tree
hop
A: 

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.

kmkaplan
+2  A: 

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.

starblue
Agreed, having binaries in source control makes sense if you work together with non-programmers on a project.
driAn