Alain wrote: > The question of using Subversion instead of CVS appeared sometimes > on the list. Trac fits better with subversion. Is there any plan to > migrate to subversion ?
We will do that the minute it's supported at Savannah. When that happens is still unknown but at least it looks like it's on its way, which wasn't the case some year ago. See https://savannah.gnu.org/maintenance/WhenSvN for the relevant information. We do have a subversion repository for use with trac, however, but it only mirrors the trunk of the cvs repository. > Is the multi-board branch dead ? (http://trac.gnugo.org/gnugo/ticket/24) > It looks very interesting, i reread all the thread and a huge job > has been done, approximately at the same time as 3.7.4. This > seems not to far to hope an easy revival ? > > where did the branch began ? (3.6 , 3.7.1 ... ?) The cvs browser at Savannah should be the easiest way to track that down. > what is the cvs command to get this branch ? Don't remember, I'm almost exclusively using subversion these days, except for checking in GNU Go code. > what are the known problem with this ?(except minor 10% slow down) The main problem is that it makes all code more heavy (passing around board pointers everywhere) and that we sort of don't really know how to make good use of it. > I read that some test suite passed, so it might be in rather good shape. What > is the remaining job? and last, what can be done for helping ? In the end this is all related to multithreading, without that the multiboard approach is not worthwhile. But multithreading comes at a potentially high price, with high risks of introducing subtle and difficult to reproduce bugs, not to mention race conditions. Anyway, my current thinking is that the most interesting way for GNU Go to make use of additional CPU power is to include Monte Carlo techniques. Now Monte Carlo has the interesting property that undo functionality is of little use, as is a large fraction of the board functions implemented in GNU Go. Therefore it would make sense to use a different board implementation for Monte Carlo, and since it's not used anywhere else it could from the beginning be written for multiboard and multithreading, where the latter would be localized to a smallish amount of code and not affect the whole engine. Incidentally I'm already working on a separate Monte Carlo board. /Gunnar _______________________________________________ gnugo-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnugo-devel
