No doubt about saving src code into SCM, but what about the generated builds ? Instead having them into a file system, would be a good practice to save them into a SCM considering that you have many customers with diff versions and within reach ?
Asked
Active
Viewed 1,182 times
1
-
I have lets say a JAR that is my "binary", mysoft-1.0.0.jar and I save it in the SCM /versions/mysoft-1.0.0.jar . Tomorrow I do a new version and instead of overwrite the same file (allow the scm to version control the binary) I will write another file mysoft-1.0.1.jar. I want to use the SCM as a secure file system (because my server is often backed up, maintained, etc. – Rodrigo Asensio Aug 05 '11 at 16:17
-
You might find this answer helpful in that case. [Best practices to store jar files in vcs like svn or git](http://stackoverflow.com/questions/3329041/best-practice-to-store-jar-files-in-vcs-svn-git) – Ocaj Nires Aug 07 '11 at 08:17
3 Answers
2
You should not store generated binaries in version control. They should be the output of compiling and bundling the source code in your repository using the build scripts in your repository. If your builds are not reproducible for some reason, go fix the cause. Don't abuse version control by applying it to artifacts that don't evolve.
Note that this is all with reference to your binaries. If you have external dependencies, it is sometimes reasonable to keep them under version control, as they are inputs to your build process. This would be things like third-party libraries or toolchain components.
If you just need a backup of what you've shipped to customers, drop complete images or archives in the same backed-up file system that you keep your repository on. There's nothing special about keeping them in a VCS's extra layer of packaging on top of the file system. If anything, that's less reliable, as there's one more point of possible corruption. In either case, if you care about the integrity of those archived builds, you should take cryptoographic hashes of them when they ship, and record those alongside the archives, so that you can verify them later. If you're being really paranoid, sign the checksum file with a private key that's not kept on that file server.
Phil Miller
- 36,389
- 13
- 67
- 90
1
Of course you won't be able to view diffs of the binaries, but any kind of file can be put into version control.
I've never had a problem with binaries in SVN, but if you aren't careful, in some other SCMs (Git, possibly others) they may become corrupted.
If you're using SVN, another thing to consider is that anytime you upload a new version of the binary, the amount of space used by your repo will grow by as much as the size of the binary. This happens because it doesn't really make sense to diff binaries, so every successive copy has to be stored whole. So if server secondary storage space is an issue, or your binaries are large, you may want to consider an alternative solution.
So... are you using SVN? :)
ACK_stoverflow
- 3,148
- 4
- 24
- 32
-
I'm not using Maven and wont use it. Yes SVN is my SCM. I know about the binaries copy which will be not a problem due that the new version will be a complete new file in other path. I wont use svn to "version control" my versions. Just as a trustful file system to put the builds. – Rodrigo Asensio Aug 05 '11 at 16:06
-
Yeah I've never had any trouble keeping binaries in SVN. It doesn't seem like the most elegant solution, but it should work. – ACK_stoverflow Aug 05 '11 at 16:21
-
-
This isn't the original place I found this information, but here it is: https://git.wiki.kernel.org/index.php/GitSvnComparison#Line_Ending_Conversion – ACK_stoverflow Aug 08 '11 at 14:53
0
It's not recommended to save generated artifacts into SCM.
Don't know what kind of program you're developing, for Java project, the good practice is using Maven to build and storing artifacts into Maven Repository. Please read this article for more about Maven Repository and why not put binaries into SCM.
aleung
- 9,848
- 3
- 55
- 69