Re: Tree-conflicts: HEADS UP: update failure with tc-siblings :0

Quoting Julian Foad <julianfoad_at_btopenworld.com>:

> On Mon, 2008-11-17 at 14:18 +0100, Stephen Butler wrote:
>> Quoting Greg Stein <gstein_at_gmail.com>:
>>
>> > You need to make it loggy. Writing conflict data immediately will put
>> > the directory in an inconsistent state. Consider the metadata at the
>> > precise time you write it. You will have a recorded conflict on a file
>> > that might not even exist, or on the wrong file. Or wrong revision.
>> >

> I think the problem is caused by having functions such as
> svn_wc_add_tree_conflict() that claim to update an entry by writing and
> running a log file. That doesn't achieve what callers expect. A
> (semi-)public function should not use an already-open adm_access and
> return with it out of sync.

Yes, we shouldn't update the entries file directly when the rest
of the code is loggy.

>
> I can't quite see how the log handling in do_entry_deletion() is
> supposed to work. Will email separately.

All of the merge operations that are relevant to tree conflict
detection write and run their own logs before exiting.

The update delete operation, do_entry_deletion(), also writes and
runs its own logs. I presume this is because a deletion has to
be finished before the item can be replaced.

The rest of the relevant update operations use the parent dir's log
accumulator. Writing and running logs is postponed until the parent
dir's close_directory().

When we detect a tree conflict, we skip the rest of the function.
Before exiting, we run logs if the function would normally do so
(i.e., if it's a merge op or do_entry_deletion()).

What I have in mind is one loggy command per tree conflict. When
logs are run, the tree conflicts will be appended to the entry one
at a time.

To continue to use the <modify-entry> command would be tricky,
because the tree conflict detection code has no access to the
already-written log files. We could keep a list of tree
conflicts in memory, then write it out to a single <modify-entry>
log file, but seems like an end-run around the loggy system.

>
> There might (should?) be a way of re-synchronizing, which would be
> perhaps a better solution. I'll solicit WC experts' help.
>
> Does that sound right?

I think we just have to append tree conflict data loggily, and
run the logs in each function that would normally run them.

Steve

-- 
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org