Would be nice if there would be a few people discussing the trade-offs. As my current project comes slowly to an end I will find some time to be active in this.
My proposal would go like this: - the most important thing to achieve is to have sources of projects available - in the beginning we can live with a setup that might be a "little" cumbersome to use A first solution that is easy to set up and that is reliable is: - www.squeaksource.com is the master where all projects are created - mirrors copy source files via rsync to distant machines and provide WebDAV shares with the same directory layout as squeaksource - squeaksources WebDAV is read-write while the mirrors WebDAVs are read-only. This way rsync is already the best choice. There can be only data transfered from squeaksource to a mirror What use case will be feasible: - a user searches for a project on squeaksource and copies the MC http repository snippet in his monticello browser - now the user has the central read-write location at his side. - if squeaksource is down a user picks another http repository from a list of mirros, enters it in monticello and downloads source from the new location - if the user is a developer and wants to store a project change now gets an error if he tries to store it on the mirror. The developer than just clicks on the central location and stores it there Things to solve: - where is the list of mirrors maintained - how would tools like metacello copy with different locations. I know there is support for alternate locations but AFAIK only if there are placed inside the ConfigurationOfxxx. I don't think it is an option to put in mirror locations in the ConfigurationOfxxx. - files can still be uploaded to squeaksource more or less "anonymously" which interferes with inria policies So far... Norbert On 22.07.2010, at 10:08, Stéphane Ducasse wrote: > 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
