[DGD] Managing a persistent mud.

[bart at wotf.org]

I've had to deal with the issue you mention for quite a few years, through
back then I was using svn instead of git. The version control system in
question doesn't matter much.

The reason is that allowing edits to code on a live mud that is supposed to
support a persistent world is a really bad idea, and except for some
'emergency' cases is something to really avoid.

First of all, code itself should be carefully tested before being introduced
on the live mud. You can't fix simple mistakes with a reboot as there will be
no reboot (or you won't have a persistent world)

More important, introducing code changes is fairly easy and a well defined
process, but you also may have to convert data when your code changes, this is
a far less well defined process as it is closely related to the actual changes
you make, and my experience is that you really really should test such
conversions before introducing them.

There are many more reasons to want control over changes introduced on a mud,
but those 2 things really make for requiring a formalized process for
introducing code changes, at the very least going through a test copy.

With regards to this you cannot run a persistent mud as if it is a traditional
lpmud, it requires far more careful planning and additional control for
introducing changes, failing to do so will simply result in having to revert
to older state dumps often (hint: make sure you *DO* keep copies of statedumps
going back quite a bit to be able to recover from cases of creeping
corruption) which means throwing away the achievements of your players, and
the (non coding) work of your builders.

So, I strongly suggest to reconsider the idea of allowing live edits on a
persistent mud, in my experience it causes way more trouble and work then
teaching your would-be coders to work on a development copy and to follow a
more controlled change management process.

Additionally, *building* on a persistent mud should generally not require
changing code, rather, it should consist of cloning and configuring objects.
Such objects will simply exist util they are explicitly destroyed again, so
there really isn't a reason to write dedicated code for a specific room for
example, rather, cloning the standard room and configuring it properly
(connecting exits, adding descriptions etc) is how this should be done. As a
result, your standard room should also contain all functionality typically
required from a room instead of leaving that to 'domain coders'.

In this case, proper process is the solution, technology is not, its merely a
tool to enable the process.

Bart.

On Sat, 29 Aug 2015 14:03:39 +0100, Gary wrote
> Hey All,
> 
> I've been reading about persistent muds and DGD/kernel lib support 
> for this and it raised a question of how code is managed in such a 
> mud. Not in regard to recompiling objects in DGD, that's reasonably 
> clear from the docs and support the kernel lib provides. I mean 
> managing the code from an editing and upload perspective.
> 
> For most projects I'd edit locally and then push to a git repo for other
> team members then at various milestone points a build would be made and
> deployed. For a persistent mud this might simply mean sync'ing over the
> new code changes (perhaps deploying via a git pull or applying 
> patches to the live server code) and then logging into the server to 
> run a full recompile/upgrade.
> 
> If the mud however also allows for guest builders who can add/edit code
> within their own zones live via either OLC or something akin to an SFTP
> upload to directories they have write access, the git approach 
> starts to feel a little iffy although perhaps still workable.
> 
> Do any of you know how persistent muds have handled this or had any
> experience with various deployment methods yourself? What pros/cons did
> your approach have?
> 
> On another note, did the Skotos code base ever see the light of day?
> 
> Regards,
> 
> Gary
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/