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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
