Re: [RFC] v2 Tree conflict resolver spec.

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
>