Just a few comments from me on the first half of Neels' response to this
draft.
Neels J Hofmeyr wrote:
> Daniel Näslund 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 the
> conflict resolution conform with adjacent WC states. (attention, high degree
> of meta language. No need to understand me :P )
I assumed Daniel meant, "The hard part is figuring out what state WE
WANT the WC to be in ...".
> >
> > 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=theirs should be identical to
> 'svn revert'.
>
> In general, 'svn update' should pull in the complete BASE tree state of the
> update's target revision regardless of conflicts, and any conflicts should
> be local schedules on top of that.
Yup. And with merge, --accept=mine should be identical to 'svn revert'.
Those two sentences state a fundamental property of the behaviour that
we want. We should write them in the document as a hard requirement.
> >
> > ### 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.
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 somebody
really doesn't want it.
The tricky bit there is just how to store and how to keep track of and
how to access that data.
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.
[...]
> >
> > Contents
> > =========
> > Problem definition
> > Requirements
> > Terminology
> > Use cases update/switch
> > Use cases merge
> > API changes
> > User interface
[...]
> > Terminology
> > ============
> > In this document, WORKING means the user's version, which possibly has
> > text, property and/or tree modifications relative to the BASE; it does
> > 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...
> Below, when I say 'BASE tree' or 'WORKING tree', I mean the wc-ng metadata
> 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 about
> props to be missing below.)
Terminology is crucial. We'll never understand each other without
agreeing on the terminology.
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 necessary
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:
* what I checked out (or last updated to) - which is a mixed-revision
copy of parts of the repository;
* what I expect to check in - which is the versioned files and dirs on
my disk, plus "svn propget" to see props.
- Julian
Received on 2010-02-09 16:34:45 CET