Hey guys,
we have to get things back in line... attempting:
1. Neels suggests fix of TC-sibling bug by collecting all added TCs in an
apr_array until closed_directory().
2. Steve suggests writing TCs immediately, Neels implements.
3. Greg says "no".
4. Steve reverts (2) and says he's onto fixing it by adding an
<wc-entry-add-tree-conflict/> instruction to the log (suggested by neels).
5. Julian says that this is not fixing the synchronization problem.
6. Julian says he likes solution (1) above.
7. Steve explains the concept of 4 in more detail.
8. Steve verifies that it is necessary to write TCs on delete immediately.
9. Julian acknowledges that "update" may not be entirely loggy after all.
To 1, 6: There would be the log on the one hand and the TC list on the other
hand. Afterwards, there is no way of knowing *when* in the log the TCs were
added. However, if that doesn't matter, this solution would be nice in that
it only once reads pre-existing conflicts and appends new conflicts in one
chunk instead of resizing buffers on every new tree-conflict. (whatever.)
To 5: Julian, I don't really understand the synchronization problem with
this solution you are talking about. It writes distinct "add this conflict"
commands to the log which get run within the sequence of the log. Each one
performs a "read first" to append one new conflict, which is a little bit of
overhead. But the sequence of events should be proper, shouldn't it? Note,
this one requires creating a new log command, one that *appends* a conflict
to the parent's entry instead of *replacing* conflicts in the parent's entry.
To the current situation:
Who is doing what now?
As to "what": I am still convinced that (5) is the best solution.
As to "who": Steve, should I continue on this or would you like to?
(I'm often not entirely clear on whether you are really taking over
something I've been working on or getting back to other stuff. We *could*
actually work alternately on the same issues, because I work at nights and
you work at daytime (I assume). For example, at the end of the working day,
each of us posts a diff of any unfinished work on a joint issue and the next
guy tries to make sense of stuff from there... :) Or we use branches. That
used to work pretty nicely IMHO.)
Anyway, please be more verbose about things we are working on together. :)
I'm letting you guys reply on this and am first looking at something
entirely different. If we are clear on this tomorrow, I would gladly
continue to fix it, unless someone else says he's busy on it.
Thanks,
~Neels
Julian Foad wrote:
> On Sun, 2008-11-16 at 06:39 +0100, Neels J. Hofmeyr wrote:
>> Neels J. Hofmeyr wrote:
>>> 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.
>> I've also done some digging now and am busy fixing it. (Steve, I know you
>> are or have been on this. Shout if I'm duplicating your work or something.)
>> Let's explain the problem:
>>
>> run_log() reads two modify-entry commands from a log file:
>>
>> <modify-entry
>> name=""
>> tree-conflicts="B:dir:update:edited:deleted"/>
>> <modify-entry
>> name=""
>> tree-conflicts="mu:file:update:edited:deleted"/>
>>
>> It calls log_do_modify_entry() on both of them.
>>
>> Common sense says that this tree-conflicts data should be concatenated.
>> But log_do_modify_entry() *replaces* the information that is already there.
>> So the first new conflict is overwritten by the second.
>>
>> Ok, let's step one layer out of this onion. There is the function
>> svn_wc__loggy_add_tree_conflict() which writes these tree-conflicts to the
>> log. This function first checks what other tree-conflicts there are in the
>> entry, adds the new tree-conflicts data and replaces the whole
>> tree-conflicts data in the entry with the new list.
>>
>> The problem is that if in one directory, two tree-conflicts appear in the
>> same run and are recorded using the same log, the second tree-conflict
>> addition again reads the *old* list of conflicts from the entry, appends the
>> second entry and writes the whole thing out. So, any earlier tree-conflicts
>> that were queued in the log file and aren't in the official entry yet get
>> overwritten with the latest one.
>>
>> I am busy on a patch that first collects all new tree-conflicts upon update
>> in the parent dir baton as svn_wc_conflict_description_t* in an apr_array
>> and logs them all at once on close_directory() (in update_editor.c).
>
> Neels,
>
> I only appreciated this solution that you're working on after I'd read
> and responded to the rest of the thread, and said we should try to solve
> the "adm_access entries cache gets out of sync" problem. But this
> solution you're working on is possibly a good solution too, though it
> doesn't exactly remove the source of the problem.
>
>
>> The patch won't make it today, but there are questions I'd like to send out
>> already:
>>
>> 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.
>
>
>> 2)
>> We use svn_wc_conflict_description_create_tree() to make a new conflict
>> description struct. The fact that this function also *allocates* the memory
>> makes it a little harder to push a new description onto an
>> apr_array_header_t, since apr_array_push() is also allocating memory and
>> returning it to be written in.
>>
>> I'm currently solving this by not storing conflict description structs, but
>> only pointers to them in the apr_array. I thus avoid changing the signature
>> of svn_wc_conflict_description_create_tree(), which would otherwise break
>> with the conventions of svn_wc_conflict_description_create_text() and
>> svn_wc_conflict_description_create_prop(). Do you guys agree with that, or
>> would you rather change the function signature or even signatureS?
>
> Yes, storing pointers is a good solution.
>
> - 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-18 04:01:41 CET