Reputation: 2239

SVN and binaries

After asking this question I was advised not to check in binaries into subversion. My question is then what do I do with 3rd party dlls that are required to be in the bin folder? I need to be able checkout a working copy and have that run as a website with all dlls, etc intact.

Upvotes: 30

Answers (10)

Hasson

Reputation: 1914

In a clean designed and maintained environment, you should have your own NuGet server where you can push your DLLs and even 3rd party DLLs/binaries, your code should download all required DLLs from your local NuGet server, so don't commit binaries to SVN still holds.

Upvotes: 1

Kwang Mark Eleven

Reputation: 261

If by binaries you mean executable files, the best practice is to regenerate them from source - if the source is available. If by binaries you mean non-text files, I can tell you that I use SVN all the time to store non-text files (jpg images, Visio files, bmp files, MS Word 2003 documents with images and diagrams, MS Project files and similar files. I have never had any problems with corruption or anything like that. And IT IS very convenient to store and manage everything in SVN.

Upvotes: 1

J.J.

Reputation: 4872

Like Ben said. I don't put binaries that are going to change often into source control. But 3rd part dll's, ya they end up in a lib folder on my svn as well.

Upvotes: 5

Rinat Abdullin

Reputation: 23552

The guidelines are simple:

Everything that is required to rebuild the solution, should be checked in *
Anything that is generated in the build process - has to stay out

--
* Programs, tools, service packs are an obvious exception to this rule. But they have got to be listed in a file that is versioned.

Upvotes: 5

Marc Bernier

Reputation: 2996

Ideally, a SVN repository should require every file needed to build the target. So that if you bought a brand new computer, installed your compiler and SVN and then checked out the repository - you could build without having to find any other dependencies. So 3rd party libraries would be put in the repository, but targets are not.

The exception to this would be if you're SVNing the installation images. We do this here, but in a different set of repositories that our production guys use (the programmers don't).

Upvotes: 1

David Dibben

Reputation: 18784

The answers to your other question suggest you don't commit any generated files to subversion. DLLs in the bin folder are often built as part of the application, therefore, they should be regenerated rather than stored in subversion.

If the DLLs are 3rd party DLLs for which you don't have the source code then I would store them in subversion. You should put everything in subversion that is needed to recreate the application. That means your source code and 3rd party libraries or programs.

Upvotes: 55

Harald Scheirich

Reputation: 9764

In fact SVN does stores binaries a lot more efficient than CVS, for more info see the SVN-FAQ

Upvotes: 0

Victor

Reputation: 3475

Just because a file is binary doesn't you you should not check it it. The warning should be against checking in derived objects into the repository. You should always be able to build all your derived objects again from the sources. This may mean that you need to have third party binary in the repository.

Upvotes: 5

Steven Robbins

Reputation: 26599

I include any required DLLs in a DLL directory in the project and reference them from there (with copy to local). Then they can either be included in the same repository/folder, or brought in using an svn-external from a remote location (if they are shared across several projects).

Upvotes: 1

Ben Hoffstein

Reputation: 103345

I always do check in third-party DLLs (into a 'lib' folder) so that the application can build and run from a fresh checkout. I think the "do not check in binaries" rule applies to the binaries that are generated by the source code you've checked in.

Upvotes: 11

SVN and binaries

Answers (10)

Related Questions