Did you look at my undo patch? Does it seem OK?
It may be ok but it doesn't work well with handicap stones or loadsgf. My opinion is that the move stack should go into the board code in GNU Go.
What problem is there with handicap stones or loadsgf?
There is an initial position which is saved in starting_position. It is assumed that we do not want to take back moves before the starting position. So if you loadsgf you can't retract moves before the position that is loaded. The same is true with handicap stones. You can undo back to the point where the handicap is set up but not beyond it.
I didn't test the code after a load_sgf or fixed_handicap call so it's possible I missed something. Could you elaborate?
Did you look at my undo patch? Does it seem OK?
It may be ok but it doesn't work well with handicap stones or loadsgf. My opinion is that the move stack should go into the board code in GNU Go.
I didn't put it into board.c because there is already an undo that's implemented in play_ascii.c and play_gtp.c, which uses the sgf code. It seems that putting it into board.c would imply reimplementing these, which would actually cause problems for the sgf file that is being maintained at the same time.
In other words putting the undo into play_gtp.c but not board.c is a logical consequence of the decision that play_gmp.c and play_ascii.c will maintain an sgf tree but that play_gtp.c will not.
Dan