[DGD] Fwd: Kotaka development

[bart at wotf.org]

On Mon, 23 Feb 2009 02:24:10 -0500, Dread Quixadhal wrote
> The first question is.... do you need the mud itself to do the push
> into your repository?  If your game is using real files for all your
> data (as opposed to virtual objects), you might be able to just have 
> a small daemon sitting in the background that will do a cvs/svn/etc 
> commit whenever it gets a signal from the driver, or whenever a 
> particular file is touched.

Right now, pulling things from the repository is what I'm after. I am using
'external' source control now, but it would be very nice when people that have
write access to a file on the mud can pull updates or old revisions. They will
have to update the repository from their personal checkout for this.

> 
> If you do want the mud to handle it, hooking the places where the
> driver writes to files seems the place to do it.

I played with this idea, and can signal an external svn service to push
updates. At any rate, pushing updates to the repository isn't a concern for
this, pulling updates from the repository is.

> 
> This is assuming you want version control in general, as opposed to
> wanting the utilities available as in-game commands.  Then I supposed
> you'd have to implement at least some of it in LPC.

Not only do I want the commands to be available 'in-game', but I also want
them to closely coordinate updates with objectd so that the changed code can
be reloaded automatically.

Network communications isn't much of a problem, there are 2 ways to solve
this, including the network package. The bigger challange seems to be the
'patch' functionality required to merge updates with local modifications.

The goal of this setup is to be able to distribute updates to lib files, and
merge them with local changes.

Hence, this does NOT concern my own mud, it concerns a system similar to
liveugrade in the Dead Souls lib for example, and distributing to multiple
targets and being able to merge with local changes are the 2 most important
requirements. Pushing things to the repository is for now of no concern.

I'll use svn instead of cvs, but that shouldn't matter that much, specs and
open source implementations are available for both, and as said, the
networking side isn't that much of a concern, its not like its the first time
I'd be implementing a networking protocol (not in LPC either)

Bart.
--
Created with Open WebMail at http://www.bartsplace.net/
Read my weblog at http://soapbox.bartsplace.net/