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
