[MUD-Dev] Ruminations on CVS and developing in the Bazaar
pvirkkul at iki.fi
Sat Nov 28 10:35:41 New Zealand Daylight Time 1998
>>>>> "Ben" == Ben Greear <greear at cyberhighway.net> writes:
Ben> The problem is trust. The most likely scenario is that I
Ben> will have never met the ppl who want to help. How can I trust them?
Ben> Reality is, I can't really them completely. So, does that mean
Ben> watching everything they contribute to make sure they aren't
Ben> screwing something up either on purpose or on accident?? That would
Ben> seem to go against the benefits of open development....
I think issue is: do you trus to the people you working with?
If there are multiple active developers you should trust them,
otherwise I don't it is realistic even work with them in the
Then there are people who contribute only small snippets and
bug fixes. It is a good idea to require them to provide
context sensitive patches that you can incorporate into the
development tree. There is no need to give full CVS access to
such persons. As far I know CVS itself is developed in this
manner: only core development team has full CVS access, others
provide patches that one of the developers incorporates into
the development team.
Accidents happens to everybody, and best protection against
them is good backups. With CVS you however cannot completely
remove files, "removed" files are just moved to "Attic". So I
think CVS is safe in this respect.
Ben> Does anyone have any experience that they would like to share?
Ben> Any specific technological (ie CVS tricks) you think might help?
CVS is very helpful in mud development, especially in muds
where modifications or/and additions are done all the
time. Atleast in BatMUD we no longer take full snapshot
backups of our mudlib so often. Instead all modifications are
automatically committed once a day (6am) into our CVS
repository. The CVS repository is easier to backup, and it
takes even less space than multiple snapshot backups.
Right now we can restore the files based on exact date, make
comparisons based on dates, eg. how file room.c has been
changed during time period between 1998-06-11 and
1998-08-30. And all of this is possible without browsing
backups on tapes. Here is an example:
--- cut here ---
argon at cave [10:23] nroom % cvs diff -c -D1998-06-11 -D1998-08-30 room.c | cat | head -20
RCS file: /opt/cvs/lib/cvs/cvsroot/batmud/mudlib/nroom/room.c,v
retrieving revision 1.2
retrieving revision 1.6
diff -c -r1.2 -r1.6
*** room.c 1998/04/25 20:32:51 1.2
--- room.c 1998/08/21 03:04:30 1.6
*** 23,45 ****
static mapping dirmap = ([ ]);
! static mapping tracks;
argon at cave [10:23] nroom %
--- cut here ---
Above is head of diffs. From the diffs can easily be seen that
during the time peiod tracking code (basically "track" and
"wipe tracks" skills, see
The most important part is that whole CVS is invisible to
developers as most of them do not bother to learn how to use it.
Everything is done automatically, and that is very important
thing in a mud where online wizards/players ratio is around
Our WWW pages are also distributed through CVS from the
machine running the mud to the machine running the WWW
server. Every 20 minutes new changes in the mud machine is
committed into CVS and 5 minute after every commit the WWW
machine updates its WWW page tree from the CVS. The main
reason was limiting cross NFS mounting but that is not the
only advantage of use of CVS in WWW server. We could even move
the WWW server machine into a separate network (different
ISP) thus in case of broken network atleast WWW-server or the
mud should be accessible to our players. And WWW pages would
still be updated automatically from the mud machine or other
We have also full shell accounts for all our wizards
(restricted in sense that they cannot make further network
connections from their shells). Wizards can edit their own
files in the shell account. They could also checkout their own
files through CVS if they wished to do the all development
work in their own machines (their files are not automatically
in CVS), but as far as I know nobody uses this possibility.
More information about the MUD-Dev