Stephen Butler wrote:
>> CMD: svn status -v -u -q ...
>> D 2 1 jrandom /A/B/E/beta
>> D C * 1 1 jrandom /A/B/E/alpha
>> D C 2 2 jrandom /A/B/E
>> D * 1 1 jrandom /A/B/lambda
>> 2 1 jrandom /A/B/F
>
> The missing ' C' for lambda is still missing on trunk. It appears
> that two log files are written in /A/B/.svn, for lambda and for E, and
> svn_wc__run_log() reads both of them, but the content of the first log
> file isn't written to the entry.
>
> Strange. I'll keep digging.
Btw, I've changed those tests to work on different nodes, but I kept this
issue showing. Now /A/B is the node that is missing a tree-conflict persistence.
And I've got a question: subversion/libsvn_wc/update_editor.c apparently
uses different logs on different occasions.
complete_directory():
int log_number = 0;
SVN_ERR(do_entry_deletion(eb, eb->anchor, eb->target,
&log_number, pool));
delete_entry():
return do_entry_deletion(pb->edit_baton, pb->path, path, &pb->log_number,
pool);
close_edit():
int log_number = 0;
[...]
SVN_ERR(do_entry_deletion(eb, eb->anchor, eb->target, &log_number, pool));
flush_log():
SVN_ERR(svn_wc__write_log(adm_access, db->log_number, db->log_accum,
pool));
cleanup_dir_baton():
err = flush_log(db, pool);
if (! err && db->log_number > 0)
(and probably many more...)
I'm really confused by that log_number stuff, especially this last
condition. Could that be the cause of the update problem in my depth tests?
~Neels
Received on 2008-11-13 05:46:47 CET