tzlaine wrote:SVN isn't very appropriate, since it is designed to keep differences between text files. Because of this design, it just keeps around individual copies of all binary files. So every time we changed an image file, we'd grow the SVN repository by a large amount, and permanently. Also, SF doesn't allow the storage of binaries in its CVS and SVN repositories, and IIRC reserves the right to purge such files.
Anyway, the current data files are always available separately for download at
http://freeorion.sf.net/data.zip.
Hello, Zach. Your statement is completely wrong, sorry. You seem to have pasted the 'CVS limitations' paragraph from SF.net and applied to SVN, which is not true
.
From the SVN homepage (
http://subversion.tigris.org/):
-------------------------------------
# Efficient handling of binary files
Subversion is equally efficient on binary as on text files, because it uses a binary diffing algorithm to transmit and store successive revisions.
-------------------------------------
In document E04 from SF (
https://sourceforge.net/docs/E04/en/#limitations) you can find, under CVS limitations:
-------------------------------------
Binary File Handling: CVS is designed to work with text-based data. Changes to text-based data are captured as diffs. CVS does not keep diffs of binary data changes, and instead keeps full copies of each revision. This will increase the size of nightly tarballs and the on-server storage of the repository. We discourage the storage of binary data on our CVS servers as result. Before committing a binary file to CVS, read the "Handling binary files" section of the CVS manual.
-------------------------------------
But, as I told before, the same is wrong for SVN. In document E09 from SF (
https://sourceforge.net/docs/E09/en/#limitations) there is no such limitation.
This issue was solved by the SVN developers by simply applying binary diffing algorithm to *every* file, regardless of being a 'text file' or not.
About the other statement about SF's reserved right to purge any binary from CVS/SVN repositories, I remember it was not intended for images. Think of it, FO is not going to be the first or second project adding artwork to SVN. There are thousands of them currently doing it.
Again, I beg you to store all the artwork in SVN, now that the 'size' problem is away.