[Tilesathome] Reorganize SVN?

[Matthias Julius]

Knut Arne Bjørndal <bob+osm at cakebox.net> writes:

> On Mon, Oct 06, 2008 at 09:51:32AM -0400, Matthias Julius wrote:
>> Besides that, I don't see t at h as a sub-project of osmarender.  I would
>> leave tilesAtHome/ where it is now and move everything else into
>> osmarender/ which would become the only external in tilesAtHome/.
>> This would only require a couple of path changes in the client and a
>> simple 'svn up' will update all the clients out there through the
>> auto-update mechanism.
>
> Aren't you contradicting yourself here? With my layout a checkout of
> the top osmarender dir would give you everything needed for t at h,
> except maplint which absolutely shouldn't be moved under rendering
> anyway. If tilesAtHome is moved away from osmarender we will have to
> use externals to get everything, and we will be back where we are now.

Yes, but only one instead of four of them.

>
> Sub-project is perhaps not the right word, not many things are really
> sub-projects of osmarender, but they are related projects. And, well,
> the only reason for T at H is to do osmarender renderings suitable for
> use on a tileserver...

I would take 'osmarender' out of that sentence and say that t at h just
happens to use osmarender as one of its tools.  But, of course I might
be wrong here since I havn't been involved in t at h for that long.

>
> Yes, switching checkout paths are a pain, but I think it's the way to
> go to get a single checkout tree of all this related code, which would
> be really nice to have.

I guess I just don't have so bad feelings about externals.  I don't
mind them at all.

And I would really like to avoid requiring a couple hundred client
users to switch to a different path.

Changes to the client that require actions from the users should be
kept to the absolute minimum, IMHO.

We have added a couple of dependencies to perl modules.  This of
course will make it necessary for users to install those or their
clients will stop working some day after an update.  Therefore we
should compose a list of all of them to post here and maybe on the
wiki well in advance of the migration to stable.

Matthias