[MUD-Dev] Ruminations on CVS and developing in the Bazaar

[Petri Virkkula]

>>>>> "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
	beginning.

	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
Index: room.c
===================================================================
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 ****
  #undef LOG_CLEANUP
  
  static mapping dirmap = ([ ]);
! static mapping tracks;
  
  create()
  {
    items::create();
    flags::reset(0);
    weather::reset(0);
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
	<URL:http://www.bat.org/Batmud/mudinfo/skills/track.html> and
	<URL:http://www.bat.org/Batmud/mudinfo/skills/wipe_tracks.html>).

	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
	1/10.

	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
	development machines.

	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.


	Petri