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