On Mon, Nov 30, 2009 at 12:42:29PM +0100, Stefan Sperling wrote: > On Thu, Nov 26, 2009 at 08:01:30PM +0100, Daniel Näslund wrote: > > cp-add > > ------------- > > alpha has been locally copied to eta, incoming add eta > > Options: > > THEIRS:1) svn revert eta > > 2) rm eta > > 3) svn up eta > > It would help to change the wording of the spec to be more precise. > You could describe what Subversion should be doing at the level of > manipulating meta data of nodes in the working copy, rather than > listing svn commands. See the wc-ng design notes for suitable > terminology (e.g. BASE tree, WORKING tree, etc.).
Yeah, I will do that. This was an initial attempt at verifying how conflict resolving in practice would work. I will continue with the conflicts when doing a merge. Hopefully some patterns for organising the resolver i starting to show by then. > What do you mean by "svn up eta"? > > The resolver will be called during a running update. > The BASE of eta needs to be updated to the new revision no matter what, > otherwise a tree conflict can put you in a cycle that prevents you from > updating forever. That's something that I do need to remember! > Do you mean something like "replace eta in WORKING with the new BASE > that came in during the update"? Yes, that is exactly what I mean. I plowed through the WC-NG docs last summer and understood... Not much of the states in the versioned tree. This time around WORKING, ACTUAL and BASE might actually mean something! Thanks for your feedback, Daniel