[Tilesathome] Contacting T at H User

[Matthias Julius]

Knut Arne Bjørndal <bob+osm at cakebox.net> 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