ok thanks for the explanation. Now I do not know who have the time to build such a set up. If we can prototype a version then we could after offer to have it maintain by the inria engineers and this is good because it will reinforce also our presence inside.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project