Knut Arne Bjørndal <[email protected]> writes: > I think it's a very bad idea to more or less reinvent the fully > functional and fairly round wheel called svn and replace it with lots > of code we would then have to debug and maintain.
Sure. It only could be extended in that the server could monitor changes to the stylesheets and notify clients. > I think a better way to handle this is to have the client send both > the client name (which isn't bumped very often) and version info of > every involved component - that is all loaded perl modules (which you > easily can have perl dump), rasterizer, java and stylesheet versions. > > The server wouldn't validate all of these, but it would check for a > minimum version number of some things, and it could blacklist known > bad versions of specific components. This would make it possible to > blacklist for example known non-working versions of Batik or Inkscape > much faster than today. I think that would be overkill. If there would really be some version of some lib that screws up the client we can deal with it then. > > I'm not sure using svn rev numbers is optimal, since those can differ > in some cases (at least it does for svk users). How can they differ? > We could either put a version number in the stylesheets (which > authors have to increment manually), or base it on some other svn > prop, is there for example one that contains the revision date? The date might not be precise enough. > > Manual version numbers would also work for clients that don't use svn. SVN can be set to substitute keywords such as $Revision$ into the files. The problem is that every file can be on a different revision. Matthias _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
