Important Orbiter-Forum.com switching to a new cloud provider

Xyon

Puts the Fun in Dysfunctional
Administrator
Moderator
Addon Developer
Webmaster
GFX Staff
Donator
Beta Tester
Joined
Aug 9, 2009
Messages
6,622
Reaction score
70
Points
123
Location
10.0.0.1
Website
www.orbiter-radio.co.uk
Tuesday? There are no new beta releases available yet, anyway - martins, dbeachy1 and I are putting together a solution to adequately distribute the next one, as certain components will be quite large in size and not version controllable.
 

orb

O-F Administrator,
Administrator
Joined
Oct 30, 2009
Messages
14,023
Reaction score
0
Points
0
Alternatively, the latest available beta from January 1, 2013 could be simply packaged into a zip file for people wanting to download it, before it will available at SVN.
 

Face

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,111
Reaction score
44
Points
73
Location
Vienna
Tuesday? There are no new beta releases available yet, anyway - martins, dbeachy1 and I are putting together a solution to adequately distribute the next one, as certain components will be quite large in size and not version controllable.
In the meantime people could download a beta version from my mirror, if there really is the need.

As for large data not being version controllable: we do so at work with Mercurial's largefiles extension, keeping only hash-codes of files in the database, but transmitting the actual large content via standard means (FTP, HTTP, torrents). Average size of such assets is around 500MBs, mostly ISO images.
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
1,487
Reaction score
19
Points
38
Alternatively, the latest available beta from January 1, 2013 could be simply packaged into a zip file for people wanting to download it, before it will available at SVN.
No (immediate) need for that, I think (can't speak for others, though).
As long as there is nothin' new, it's O.K. The repository access is only REALLY useful if there are any changes ;)
/Kuddel
 

Xyon

Puts the Fun in Dysfunctional
Administrator
Moderator
Addon Developer
Webmaster
GFX Staff
Donator
Beta Tester
Joined
Aug 9, 2009
Messages
6,622
Reaction score
70
Points
123
Location
10.0.0.1
Website
www.orbiter-radio.co.uk
In the meantime people could download a beta version from my mirror, if there really is the need.

As for large data not being version controllable: we do so at work with Mercurial's largefiles extension, keeping only hash-codes of files in the database, but transmitting the actual large content via standard means (FTP, HTTP, torrents). Average size of such assets is around 500MBs, mostly ISO images.
That'd work if it was mercurial, and we're talking planetary textures and heightmap data ~100GB in size, and all largely static binary data. I don't think SVN has the same large files capacity.
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
1,487
Reaction score
19
Points
38
I don't think SVN has the same large files capacity.
Subversion per se does not have a filesize limit:
A nice feature of Subversion is that by design, there is no limit to the size of files it can handle. Files are sent "streamily" in both directions between Subversion client and server, using a small, constant amount of memory on each side of the network.
Of course, there are a number of practical issues to consider. While there's no need to worry about files in the kilobyte-sized range (e.g. typical source-code files), committing larger files can take a tremendous amount of both time and space (e.g. files that are dozens or hundreds of megabytes large.)
To begin with, remember that your Subversion working copy stores pristine copies of all version-controlled files in the .svn/text-base/ area. This means that your working copy takes up at least twice as much disk space as the original dataset. Beyond that, the Subversion client follows a (currently unadjustable) algorithm for committing files:

  • Copies the file to .svn/tmp/ (can take a while, and temporarily uses extra disk space))
  • Performs a binary diff between the tmpfile and the pristine copy, or between the tmpfile and an empty-file if newly added. (can take a very long time to compute, even though only a small amount of data might ultimately be sent over the network)
  • Sends the diff to the server, then moves the tmpfile into .svn/text-base/
So while there's no theoretical limit to the size of your files, you'll need to be aware that very large files may require quite a bit of patient waiting while your client chugs away. You can rest assured, however, that unlike CVS, your large files won't incapacitate the server or affect other users.
Versioning large files might not be the best idea anyway. Your Apache (or whatever) HTTP Server might need to be configured as well to cope with that long transmissions...In theory it should work, but how reality deals with that might be different ;)
 

Face

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,111
Reaction score
44
Points
73
Location
Vienna
That'd work if it was mercurial...
Well, it is already, so to say. These days conversions between SVN/Git/Mercurial are as cheap as it can get.

But I think I see what you mean, continuing this work-mode with SVN might not make much sense if your SVN-server has to host 100GB of file data for each checkout instead of each clone, regardless of whether or not SVN can actually deal with large file sizes. And of course it would be a single point of failure, as with every centralized versioning system.

Still I'd suggest to not dismiss versioning too quickly, given that decentralized systems exist, and file sharing in this size category today uses even a very similar paradigma (torrenting).
 
Top