Offhand, I think it would make the most sense to not start a new variation unless the user explicitly says to -- say by selecting New Variation from a menu or pressing some new on-screen button. If the user doesn't say to start a new variation, then entering a move after backing up would throw away the moves that were backed over.
On Wed, Oct 13, 2010 at 12:56 PM, h.g. muller <[email protected]> wrote: > At 09:28 13-10-2010 -0700, Arun Persaud wrote: > >> Hi >> >> I have to say that I never use variations either, but I don't understand >> why creating more variations leads into memory problems... >> >> Shouldn't we just have the whole game including variations in a >> tree-like structure and then a linked list without any branches that >> points to the current/active variation? Going back and forth would just >> move along the current list and whenever you add a new variation you add >> it to the tree and update the current list and when you move back and >> forth and there are multiple branches in the tree they should be shown >> somewhere in a windows, so that you can select the branch you like or >> you just show the whole tree in a window and people can click on any >> leave in it to select the branch they want to be on. >> > This would be one way to do it, but it is not the way it currently works. > But this is mostly an implementation detail; the basic problems stay the > same: > if you only add branches, and never delete them, at some point your memory > will > fill up. And if you delete them, the question will arise upto where you > want to > delete a branch. To the branching point furthest from the root? Or to the > branch > point that was last created? The whole sub-tree after the current position? > And the choice when a newly entered move should start a new branch, > or replace an old one, still has to be made. > > > Perhaps it would be good to rewrite this part if there are problems with >> it? >> >> Arun >> > > >
