FreeOrion

Hello, developers. It might have been discussed earlier, but was not be able to find it. I would like to know why the artwork is not under SVN control, in a separate module called freeorion-data or something like that. Maybe does SF pose any problem in terms of allocated space in SVN for a single project (I guess no, but...)?

It would be easier for packagers and everyone else to be able to access latest designs, snapshots and prompt fixes for problems in the current collection without releasing the entire dataset as a whole.

Best regards,

Ender.

_________________
Debian developer

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.

_________________
Debian developer

Alright, I finally got around to reading the SVN docs and SourceForge docs regarding this. It looks like I either misremembered the SF policy on binaries in repositories, or they changed their policy. So, I'll be adding these binary files to SVN "soon".

Great! Many thanks, Zach. It will be a great addition.

Best regards,


Ender.

_________________
Debian developer