[Tilesathome] Reorganize SVN?

[Knut Arne Bjørndal]

On Mon, Oct 06, 2008 at 11:48:11AM -0400, Matthias Julius wrote:
> 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.

As far as I know the reason for t at h was osmarender, and I've never
seen any support for other osm->svg renderers in there, so how it can
not be seen as an osmarender-related project is besides me.

> > 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.

It makes for a mess when developing. I already have a couple of
osmarender checkouts, and that extra for each of the couple of t at h
checkouts I have makes it even harder to keep track of where
everything is.

> 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.

Yes, we should try to limit disruptive changes, but I don't think we
should keep the current workarounds (yes, I consider our svn externals
workarounds for a proper dir layout) just to save client renderers
from running one command.

Why don't we use this situation as an opportunity, call it a big
version upgrade, and list the things people have to do:
* Install Error.pm
* Install IPC::Run
* Install Class::Accessor
* svn switch ...

-- 
Knut Arne Bjørndal
aka Bob Kåre
bob+osm at cakebox.net
bobkare at irc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4167 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20081006/23ae3947/attachment.bin>