On 22.07.2010, at 09:19, Stéphane Ducasse wrote: > > >> On Thu, Jul 22, 2010 at 2:10 PM, Stéphane Ducasse >> <[email protected]> wrote: >>> how your server is backed up? >>> Then we should pay attention not to end u having multiple of sources around >>> before we can deal with the mess >>> this may create. >>> We got the ok from inria for a webdav server (the problem was that from a >>> security view point, having >>> an anonymous write was a no go. So now we will do >>> - write only inbox >>> - inputs are then checked to be only .mcz >>> - then automatically copied to a readonly inbox >>> - pharo* projects should be >>> read and write for the people registered to the forge. >> >> >> Great, this is only for Pharo or you want to mirror also Squeak projects ? > > We do not know. For now at least the Pharo* repositories and the ones that > are central XML-.... > Ideally I would prefer to have everything in the same place and we have no > problem hosting squeak projects. > Now what is more important is build a kind of process to clean projects, > there are a lot of projects which got created > but > - were never really used > - are students code exercises > So may be starting with a metacello config for every working one could be a > start. > > The problem is that you lose all the nice aspects of squeak-source: UI to > manage the commiters..... > So we should check with the effort of dale and philippe and others on the > gemstone version of squeaksource. > I don't think you loose anything. You need to separate write and read. You still create a project on squeaksource and this creates a WebDav directory for it. If the mirrors sync than this project is replicated to all other mirrors. From this point in time a client can just use a list of mirrors to fetch the source from a different server if the master is down. It is easy as this. No need to install squeaksource on the mirrors. This scenario even applies if you take the gemstone based squeaksource into account. To me it is really just a matter of who is doing the failover handling: user or client.
Norbert _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
