[crossfire] Re: [Crossfire-devel] Made a CVS upload error: /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz

Mark Wedel mwedel at sonic.net
Thu Sep 29 23:37:07 CDT 2005


Mitch Obrian wrote:
>
     
      I uploaded the tar to cvs at
     
     >
     
      /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz
     
     >
     
      in my tiredness last night. Can someone remove the
     
     >
     
      tarball
     
     >
     
      /maps-bigworld/unlinked/mlab-devel/mlab-devel.tar.gz
     
     >
     
     
     >
     
      I uploaded it to the correct path today.
     
     
  My personal opinion is that mlab-devel.tar.gz should not be in CVS.

  The untarred files are already there - the tar is just redundant data.  I 
can't think of any compelling reason why it is needed - presumably anyone tha 
wants to use it is smart enough to do be able to do a 'mv' from the the current 
directory.

  It is after all sucking up an extra 5.5 megabytes of space.  Mind you, that 
isn't a lot, but in terms of bandwdith to download it (doing a cvs update -dP on 
entire map directory, which is often common procedure) it is non trivial.

  And since it is binary, you have to get the entire thing.  IMO, CVS is not 
well designed to hold binary files, and certainly doesn't deal well with really 
big ones.  So unless there is a compelling reason it needs to be there (and if 
there is, please provide it), it should be removed.

  Now as far as the untarred mlab stuff, I'm more mixed on that.

  In the past, the stuff in the unlinked directory was basically maps that came 
from whatever sources and needed to be integrated, but did not have anyone 
actively developing them.  So it was basically a holding area until someone 
found the time.

  The mlab maps obviously do not fall into that case - they are clearly being 
actively developed, and the person doing so has CVS.

  One problem that arises from this is that there really isn't any way for 
anyone to integrate the mlab maps - your trying to integrate a moving target.

  The other is that this really just seems to be a way to avoid the mapguide - I 
know Mike doesn't want to follow our map directory layout or some other areas of 
the mapguide.

  But it seems to me that either either the rules should be followed and these 
maps checked in the right places, or they shouldn't be checked in at all.

  I don't like the idea of stuff being thrown into CVS for someone else to take 
care of.  I could see this leading to similar things for the client or server 
code - someone throwing code into a 'patches' or 'test' directory or something 
that doesn't meet coding guidelines - either the stuff should be mature enough 
to be checked into CVS, or it shouldn't be.

  The other possiblities is to make a new CVS repository for this - instead of 
unlinked being a directory in the maps tree, make a maps-unlinked CVS repository 
for all this stuff.

  But then I'm still stuck figuring out what is going to happen with all this 
mlab stuff - either the correct rules should be followed and this integrated in 
properly with the maps, or it probably shouldn't be there.




>
     
     
     >
     
     
     >
     
     
     >
     
     
     >
     
     
     >
     
      __________________________________ 
     
     >
     
      Yahoo! Mail - PC Magazine Editors' Choice 2005 
     
     >
     
     
      http://mail.yahoo.com
      
      
     >
     
     
     >
     
     
     >
     
      -------------------------------------------------------
     
     >
     
      This SF.Net email is sponsored by:
     
     >
     
      Power Architecture Resource Center: Free content, downloads, discussions,
     
     >
     
      and more. 
      
      http://solutions.newsforge.com/ibmarch.tmpl
      
      
     >
     
      _______________________________________________
     
     >
     
      Crossfire-devel mailing list
     
     >
     
     
      Crossfire-devel at lists.sourceforge.net
      
      
     >
     
     
      https://lists.sourceforge.net/lists/listinfo/crossfire-devel
      
      
     
    


More information about the crossfire mailing list