[vworld-tech] [TECH][TOOLS] SCM systems

[ceo]

Bruce Mitchener wrote:
> Hey Adam,
> Are you looking for something only for your own internal use?  Given 
> that you provide licensable software, do you see needing to have your 
> licensees using Vesta as well? Will the limited platform availability of 
> Vesta matter for that?
> 

Right now, the state-of-the-art low-cost systems are so poor that I 
would bend over backwards to replace them with something really good, 
just for internal use.

However, Vesta's replication-management (and security) present the 
theoretical possibility of making this the preferred method of 
distributing code to licensees too; give them access to the Grex Vesta 
repository (which, in Vesta's global naming scheme, would look something 
like "/vesta/grexengine.com/", which is quite neat :)). Although that's 
something that we'd have to look into entirely separately, mainly 
looking at a combination of security and how tricky it would be for 
customer sites to use.

I'm worried that Vesta appears entirely dependent upon NFS for all 
distribution/replication/etc, and I'm hoping (probably in vain) it'll 
turn out to happily work with any remotely-mounted-filesystem :). E.g. 
something using SFTP might be nice (just a thought...)

> Another big issue for the usage of revision control systems in an online 
> game is one that prevents me from feeling entirely comfortable with 
> pretty much every system for online game development that I've used or 
> looked at:  None seem to provide a good content pipeline that integrates 
> with a development and deployment plan.
> 
> Are you planning to use Vesta for that as well?  Or do you have some 
> alternative system?
> 

Can you be more specific about your requirements? As far as the content 
pipeline goes, have you used any of the NXN Alienbrain (IIRC?) tools?

IIRC NXN's stuff was pretty good when I looked at it 3-4 years back - at 
least, it seemed to fulfil all the criteria I expected of such a 
product, even though intially I was surprised at how young it was (i.e. 
because most people were exclusively using in-house tools for decades).

None of *our* (as opposed to partners) work has had complex content 
pipeline requirements yet, so simple non-specialised systems have been 
perfectly good enough

Deployment, OTOH, has been a royal pain, mainly because Java doesn't 
help at all. For packages there's no versioning, dependency maintenance, 
in fact there's practically nothing at all, apart from the ability of a 
ZIP file to statically (hard-coded; can't be altered at runtime, not 
even by the user, unless they repackage the classes!) reference other 
ZIP files (by absolute name!) that contain classes it wants to share.

This makes some of Sun look particularly moronic, given that J2EE 
depends upon this non-existent package management; official hacks have 
been added (mostly *specifically* for J2EE, according to the official 
docs) but it is still almost entirely useless and you have to roll your 
own packaging system.

I appreciate that this is not at all easy (c.f. how wrong and bloated 
RPM managed to get things ;)), but it's needed by almost every serious 
development team and is a prime candidate for inclusion in Java's 
standard libs / JVM specs (by reference to all the other things that 
already are, and which have been added..)

</rant>

It just irritates me that we've had to develop packaging and deployment 
(and, hence, runtime package-management) systems all from scratch, which 
feels rather like implementing regular-expressions from scratch - it's 
something you shouldn't be doing in a modern, mass-market commercial 
programming language :(.

OTOH, we now have a tolerably decent deployment system with full 
source-code, so it's not all bad :). However, keeping this up-to-date 
over time, adding features, tools, etc (automatic distributed deployment 
comes to mind; at the moment you have to deploy on each server 
separately) is going to be expensive and ongoing :(.

Adam