[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Unconventional Subversion use/scalability

From: B. Smith-Mannschott <bsmith.occs_at_gmail.com>
Date: Sun, 31 May 2009 19:24:39 +0200

2009/5/31 Ryan Schmidt <subversion-2009b_at_ryandesign.com>:
> On May 31, 2009, at 10:37, B. Smith-Mannschott wrote:
>
>> 2009/5/31 Bernhard Glück <business_at_bernhardglueck.com>:
>>
>>> My company is developing a Massivly Multiplayer Online Game. As you
>>> might know that kind
>>> of game needs content updates often and reliably. Because of that I had
>>> the idea to use Subverison
>>> as our update technology, and i wanted to check if you think that this
>>> is a viable solution before
>>> either implementing it or implementing yet another propriatry patching
>>> techology.
>>>
>>> Our Game client at the moment has about 500 MB of "Content" files. Those
>>> are split up into
>>> textures ( 10-200 kb files ) models ( 10-5000 kb files ) and audio
>>> samples ( 10-4000 kb )
>>> We manage those by having a "Content" subdirectory in our game client
>>> install directory, where
>>> they are all placed in a strict hierarchy.
>>>
>>> What i wanted to do is setup a master server where on release of a new
>>> version the release engineers
>>> will check in the new content files.
>>> This will then be mirrored to "deployment" repositories which are apache
>>> servers with their own independent
>>> Subversion server in the background. ( so we can add new deployment
>>> servers to improve the number of users
>>> we can handle )
>>>
>>> The game client would integrate a subversion client and on startup do a
>>> svn update on the content directory from
>>> one of our deployment repositories.
>
>> I don't know from my own experience, but I do recall that initial
>> versions of Tribal Trouble [1] did this to manage their updates.
>>
>> [1]: http://tribaltrouble.com/
>>
>> I just downloaded the current version, and have found that they
>> apparently still use this method, at least on the Mac. (Mac OS X
>> includes a Subversion client.) I assume it must be working for them.
>
> Mac OS X has Subversion starting with version 10.5.0. Earlier Mac OS X does
> not include Subversion.

Hm. I'm certain Tribal Trouble has been around longer than Mac OS X
10.5, and it doesn't appear to ship with a copy of subversion (maybe
I'm just missing it). OTOH, I can see from the logs of the update
repository that it is used to distribute fixes that are Windows and
linux relevant too, so they I assume they are using subversion to
handle updates on all platforms.

>> One technical aspect that worries me with this solution is the
>> relative fragility of an Subversion working copy. What state will the
>> working copy be left it if, for example, the network connection drops
>> during an update?  Will your software be smart enough to svn clean? If
>> that doesn't work, will it punt to the user (bad usability), or do a
>> fresh check out? These issues are not insoluble, but will need some
>> thought.
>
>
> Another detriment could be the size of the working copy. If you have 500 MB
> of content you want to distribute, the working copy will be larger than 1000
> MB. Is it ok to waste over 500 MB of the user's disk space just to give you
> a convenient update mechanism?

True, rsync or some other mechanism could be a better choice.

Tribal Trouble handles this problem by having empty working copies.
The .svn directories are there, with their content, but the actual
user-visible working directories are empty. It appears (jar -tf
loader.jar) that they have written a Java ClassLoader that's smart
enough to load their classes from the pristine copies in the .svn
directories.

It's a clever hack, but it's definitely a hack.

// ben

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2357302

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-31 19:25:34 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.