I sincerely apologize for the bugginess of my mail client. >:( ~Neels
Neels J Hofmeyr wrote: >> 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
