> 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
Received on 2010-02-10 01:30:00 CET