On Fri, Mar 09, 2007 at 07:27:09PM +0100, Juliusz Chroboczek wrote: > > 1. The conflict bug. > > This is the big one. Nobody knows how to fix it (or they're not saying).
I believe we do know how to solve it, it's just that it'll be a lot of work. Jason is planning on starting work on that in the spring--but of course he'll start out by working on a simulated version. We talked about this after the Haskell workshop in the fall, and I'm quite confident that we know what the solution looks like, it's just a question of coding it up and figuring how to design a repository format that'll work with it. The basic idea is that we're going to have to give up the simplicity of storing all changes as a linear sequence. We'll have some sort of a tree of primitive changes, with some branches "cancelled". If there's more than one branch that hasn't yet been cancelled, you've got a conflict in your repository. It's not as beautiful as conflictors would be, and doesn't fit so well with the current code base, but it's intuitively obvious that this approach describes a solution, and that this solution can be represented in the existing commutation framework. One major change that's going to have to come will be that we'll no longer be able to store all the changes in a given named patch in a single file in a single order, since those which conflict with another patch will be sitting on branches in the tree. And, by the way, I expect that "cancelled" branches will be stored internally as something like a patch that has no effect. There will be lots of book keeping, but the math needed to determine the state of a repository is actually very simple, so the main issues should be technical ones (doing so efficiently, how to store it on disk, how to determine dependencies interactively when prompting for changes, etc). -- David Roundy Department of Physics Oregon State University _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
