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.
SVN and binaries
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.
Hi, I agree with your answer. However, I have set global ignores for *.dlls and now I can't commit new binaries from visual studio to SVN! Any idea how can I import it to existing project? –
Solemn
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.
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.
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.
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.
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).
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).
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.
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.
In fact SVN does stores binaries a lot more efficient than CVS, for more info see the SVN-FAQ
© 2022 - 2024 — McMap. All rights reserved.