For all other maps sans mlab I follow the map guide. However mlab was started way before these, thus it uses the flatdirectory structure so it stays working. I've seen maps break many times before, including my tavern when it was uploaded to cvs originally. Why must there be contoversy just over a file system? If I can't upload my maps to CVS where do I back them up to? Are they that worthless? I do a fair amount of CF work in arches and non-mlab maps, could I have alittle slack? Why is there opposistion just because I put the maps in their own flatlevel dir? The reasoning that mlab doesn't even deserve to be in CVS is very alienating, I've worked years on theses maps. I work nearly constantly on maps for CF. Mlab could be intergrated into CF-proper right now if I was just given the OK. If an exception to the dir rule was made. I though after being involved in CF this long the controversy was over and I could develop as a regular without asking about every change. I uploaded mlab so it would be with CF, so if my computers go down my years of work are not lost. Sure one can say "go find some other place to back up to" but... that's basically telling the person to screw off; their work is of little value. The tar is uploaded so it itself is not lost, it is only 5 megs. --- Alex Schultz < alex_sch at telus.net > wrote: > Mark Wedel wrote: > > > 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. > > > > [snip] > > > > 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. > > In terms of integrating a moving target, I don't see > how it would be any > better if they weren't in CVS. Really, the target is > still moving if one > was trying to work from Mike's periodic mlab release > tarballs, so though > it being in CVS doesn't solve the moving target > problem, it does allow > the movement of the target to be tracked better > which IMHO is somewhat > helpful to the moving target situation, even if only > slightly. > In terms of mapguide issues, I agree, though if Mike > is too unwilling to > change, it may be possible to fix many of the > mapguide issues by script > (i.e. the directory layout could be autogenerated > from the map name > prefixes that Mike is using), however chances are > this would break from > time to time, so I don't see this as too appealing > an option unless Mike > is willing to adopt such fixes for the development > of mlab. I know one > of Mike's worries with changing his current layout > is that scripts could > possibly end up creating small errors and breakage. > Question to Mike: What exactly in the mapguide are > you opposed to? And > why exactly? > > Alex Schultz > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com