On Mon, 2008-11-17 at 17:13 +0100, Stephen Butler wrote:
> Quoting Julian Foad <julianfoad_at_btopenworld.com>:
>
> > On Sun, 2008-11-16 at 06:39 +0100, Neels J. Hofmeyr wrote:
>
> >> 1)
> >> In libsvn_wc/update_editor.c, around line 1632 in
> >> do_entry_deletion(), it says:
> >>
> >> [[[
> >> if (tree_conflict != NULL)
> >> {
> >> /* Run the log immediately, so that the tree conflict is recorded. */
> >> SVN_ERR(svn_wc__write_log(adm_access, *log_number, log_item, pool));
> >> SVN_ERR(svn_wc__run_log(adm_access, NULL, pool));
> >> *log_number = 0;
> >> }
> >> ]]]
> >>
> >> Can anyone remember why that would be necessary?
> >
> > I can't.
>
> I'll give it a shot. ;) If I remove those lines, all of the incoming-
> delete tree conflicts are printed in the update output, but none are
> recorded persistently. The log_item stringbuf is local, unlike in
> other update callbacks.
>
> If the item has to be replaced, the deletion needs to be finished
> before we add the new item. So deletion needs to run its own logs.
Thanks for the insight. So it's nothing to do with any urgency about
recording the tree conflict, but rather just an implementation
side-effect of the fact that if a deletion is actually performed then
the entry needs to be updated before any potential replacement. And the
reason for that is... something to do with what series of operations can
validly be concatenated into a single log and what series can't.
Presumably something about delete-followed-by-add would break if it were
all accumulated in a single log. Maybe some parts of the sequence are
not quite loggy.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-17 17:25:57 CET