Re: [gnugo-devel] questions on subversion and multi-board branch

[Gunnar Farnebäck]

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