On Tue, Mar 30, 2010 at 05:56:54PM +0100, Julian Foad wrote:
>
> > Conflict meta data storage in wc-ng
> > ===================================
> >
> > Conflict meta data is stored in the ACTUAL_NODE table, within the
> > 'conflict_data' column. The data in this column is a skel containing
> > conflict information, or NULL (meaning no conflict is present).
>
> Is storing a record in ACTUAL OK even for a node that (apart from the
> conflict descripition) has no BASE and no ACTUAL in the WC? E.g.
> because it wasn't there and an incoming delete cause a tree conflict.
> What values would the rest of the ACTUAL_NODE columns have in this case?
Not sure right now. I guess I don't know the schema well enough yet to
answer this question. Anyone?
> > There are five types of conflicts (text conflicts, property conflicts,
> > tree conflicts, patch conflicts, and obstructions).
>
> Whoa. A patch can cause a text conflict
No. It cannot cause a text conflict. It causes a "reject" instead.
We cannot record it as a text/prop/tree/obstruction, because all we can tell
the user is "the following hunk in the patch did not match anywhere in the
target so svn does not know what to do with it." A text conflict implies
a 3-way merge which is not what patch does. Patch does search/replace.
(Remember how we figured out that diff3 merge doesn't work with patches?)
> and/or (in the future) property
> conflicts and/or a tree conflict and/or an obstruction.
It could in the future cause property conflicts, yes. But I don't see a
problem with recording that as a property conflict where operation="patch".
It currently does not flag obstructions, because patch simply skips anything
that is obstructed (like merge does today) without flagging a conflict.
I don't know if we'll ever change this behaviour. We might at some point,
but, likewise, this would become an "obstructed" conflict with
operation="patch".
> I don't think
> it is right to call "patch conflict" in the same space as those others.
> A patch is a potential *source* of the change that conflicts, not a kind
> of conflict.
Well, I think the terminology has misled you.
Maybe we should just toss that name and call it "reject conflict" instead.
I guess calling it "patch conflict" is confusing because "patch" is also
the name of an operation. An operation always uses potential sources of
conflicts (be it a delta to be merged, a property to be updated,
or a patch to be applied). But that is not why we need this new conflict
type. We need it because 'svn patch' added a new type of conflict that
didn't exist before. It does not flag this conflict yet but we will make
it do that as soon as we can.
> Sources of a conflict are:
>
> That's all for now.
>
Did you mean to make a list sources but Evolution wouldn't let you?
Stefan
Received on 2010-03-30 19:34:56 CEST