> Just a few comments from me on the first half of Neels' response to thi= s > draft. >=20 > Neels J Hofmeyr wrote: >> Daniel N=C3=A4slund wrote: >>> Design spec for tree conflict resolution in the commandline client >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> The hard part is figuring out what state the wc is in during the >>> different user cases. >> Actually, wc-ng should make that part easy. The hard part is making th= e >> conflict resolution conform with adjacent WC states. (attention, high = degree >> of meta language. No need to understand me :P ) >=20 > I assumed Daniel meant, "The hard part is figuring out what state WE > WANT the WC to be in ...".
Yes, that's right. >=20 >>> The main difference between update/switch and merge is that we don't >>> have somewhere to store the incoming changes during a merge. It would= be >>> nice if we could save a THEIRS tree. >> Also note that with update/switch, --accept=3Dtheirs should be identic= al to >> 'svn revert'. >> >> In general, 'svn update' should pull in the complete BASE tree state o= f the >> update's target revision regardless of conflicts, and any conflicts sh= ould >> be local schedules on top of that. >=20 > Yup. And with merge, --accept=3Dmine should be identical to 'svn revert= '. >=20 > Those two sentences state a fundamental property of the behaviour that > we want. We should write them in the document as a hard requirement. >=20 >>> ### Saving a THEIRS file is one thing but a tree? It could be a large= >>> ### tree. On the other hand, a file can be large too... >> With the yet-to-be-implemented pristine-store, the file largeness may = not be >> such a problem after all. >=20 > Don't worry about physical size - it's reasonable to expect a user to > have enough free disk space to store another copy of part of their tree= , > and it's easy to disable or modify that behaviour afterwards if somebod= y > really doesn't want it. >=20 > The tricky bit there is just how to store and how to keep track of and > how to access that data. >=20 > Let's not go there, at the moment, because it's secondary - it's no use= > at all until the rest of this RFC is sorted out, whereas the rest of > this RFC IS useful without having "theirs" stored locally after a > conflict on merge. >=20 > [...] >=20 >>> Contents >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Problem definition >>> Requirements >>> Terminology >>> Use cases update/switch >>> Use cases merge >>> API changes >>> User interface >=20 > [...] >=20 >>> Terminology >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> In this document, WORKING means the user's version, which possibly ha= s >>> text, property and/or tree modifications relative to the BASE; it doe= s >>> not mean the WC-NG database concept that is known as WORKING. >> argh, well, ok... >> IMHO it would be better not to overload the word "WORKING" in this RFC= =2E.. >> Below, when I say 'BASE tree' or 'WORKING tree', I mean the wc-ng meta= data >> store. When I say 'actual WC file system' I mean those files editable = by the >> user in her working copy, not the metadata. >> (Hm, I don't say that much about props though, expect some remarks abo= ut >> props to be missing below.) >=20 > Terminology is crucial. We'll never understand each other without > agreeing on the terminology. >=20 > Would it be OK with you if we just don't use the WC-NG DB terms here? I= > don't believe they are well enough understood by most of us, and I don'= t > believe they are relevant at this level of specification. Specifically,= > making a distinction between WORKING and ACTUAL is unneccessary in > defining the conflict behaviour, although of course it will be necessar= y > in *implementing* any parts of that behaviour that are right down in > WC-NG. From the user's point of view, which is a useful point of view > all the way down into the code paths that deal with tree conflicts, > there are only two trees of interest: >=20 > * what I checked out (or last updated to) - which is a mixed-revision= > copy of parts of the repository; >=20 > * what I expect to check in - which is the versioned files and dirs o= n > my disk, plus "svn propget" to see props. I think 'checked out' and 'to check in' are pretty good terms understandi= ng wise. 'Checked out' matches my concept of the BASE tree, and 'to check in= ' matches my concept of the WORKING tree node. But they are a bit clunky grammatically unless we can tie them to a noun, IMHO. How to complete the= sentences "Find the information in the checked out <noun>." ; "Register t= he incoming add in the [to-]check-in <noun>." node? tree? store? While speaking of terminology, note to self. I wouldn't want to say "delete/add/replace/switch/edit the checked-out node", because we use tho= se terms for svn operations. Better is "clear/set/swap the checked-out node"= =2E ~Neels
signature.asc
Description: OpenPGP digital signature