[crossfire] Handling of "Created" and "Modified" info in map headers

[Mark Wedel]

  I think there are several different issues we're talking about.

If we're talking about giving developers credit, and using the modified field, 
it may be reasonable to do so.

  Note that I don't believe 2a of the license applies in the maps in the context 
you indicate.  From my reading, 2a covers the case if someone else branches 
crossfire and makes changes they need to properly record the differences they 
have modified them and in what way.  I don't read it that the files in the 
original file have to have that complete change history.

  And should we even discuss the arch files, we don't have any copyright notice 
or change notice?  I would almost say those are more problematic as those are 
more likely to be new work.

  A concern I do have with listing all the modified history in map files is that 
at some point, for some maps, that could get pretty unwieldy if it is trying to 
be used as a change log history.  That is because for changelog purposes, you 
wouldn't just keep that last entry, but all of them.  So something like:

Modified:  Mark Wedel, 2008-08-25
Modified: Mark Wedel, 2008-08-21
Modified: Rick Tanner, 2008-08-16
Modified: Mark Wedel, 2008-08-01
....

  And could create a very long list (I just look at one map and it had 40+ 
commits on it over its lifetime).  So while this may not be a problem that shows 
up very quickly, it is certainly something that should be thought about - how 
long a list is too long?

  My point about adding in $Id$ strings is that provides a totally clear view of 
the map having troubles, or what map a patch was made against.  It is marginally 
simpler than having to look at the modified dates and then figure out if the map 
has been fixed.

  As for access to source system - that doesn't really make a difference - folks 
making patches will start from some base, and that would hopefully get included 
in the diff (maybe the editor should empty the $Id$ string?).  For folks running 
server from tar balls, the maps would still contain revision information, which 
would likely make tracking down bugs easier (map R9821 has this problem - pretty 
simple to check if that is the latest).  A list of Modified fields doesn't 
really convey to that user much more information, other than last time the map 
was modified, unless I have some other reference (like I did a svn update last 
night, and that modified date is fairly recent, so probably a fairly recent 
change broke it).  But that is really by the date, not by who modified it ($Id$ 
strings contain date as a note)

  All that said, if some number of Modified: fields were listed, wouldn't bother 
me that much.  But then if done, I think we might also want to clarify what 
would be appropriate data there - having a name that one can't associate with 
anyone in a real basis doesn't add much either.