[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r34345 - in trunk/subversion: libsvn_wc tests/cmdline

From: Neels J Hofmeyr <neels_at_elego.de>
Date: Tue, 02 Dec 2008 04:24:28 +0100

Stephen Butler wrote:
...
>>> > + loggy->tree_conflicts = NULL;
>>> > @@ -1720,6 +1773,7 @@ run_log(svn_wc_adm_access_t *adm_access,
> [...]
>>> > + /* Populate the tree conflict array with the existing tree
>>> conflicts. */
>>> > + SVN_ERR(svn_wc_entry(&entry,
>>> svn_wc_adm_access_path(adm_access), adm_access,
>>> > + TRUE, pool));
>>> > + SVN_ERR(svn_wc__read_tree_conflicts(&(loggy->tree_conflicts),
>>> > + entry->tree_conflict_data,
>>> > +
>>> svn_wc_adm_access_path(adm_access),
>>> > + pool));
>>>
>>> Nice, only one read of existing conflicts per parent dir.
>>> But, wait a minute, that means that the conflicts are all written out
>>> only
>>> *after* the rest of the loggy commands have been executed?
>>
>> Yes. This code runs a log file with tree conflict changes as follows:
>>
>> 1. Read the existing tree conflicts from the 'entry' in the adm_access
>> cache, into a list in memory.
>>
>> 2. Execute all of the log commands; for the "add tree conflict"
>> command, add the description to the list in memory.
>>
>> 3. Write the new list of tree conflicts to the 'entry' with
>> svn_wc__entry_modify().
>>
>> 4. Some sort of re-synchronisation:
>>> {
>>> apr_hash_t *entries;
>>> SVN_ERR(svn_wc_entries_read(&entries, adm_access, TRUE, pool));
>>> SVN_ERR(svn_wc__entries_write(entries, adm_access, pool));
>>> }
>>
>> If the "add tree conflict" command is idempotent, will this whole
>> algorithm should be fine?
>
> I think so. I'll just tweak step #2 to overwrite an existing TC silently.
>
>>
>>
>>> Could that be a problem? I don't know enough about it, so I'm
>>> paranoid about
>>> changing the order in any way... :P
>>
>> I don't understand the implications either, so I cannot say whether it
>> is OK.
>
> All of the entry updates (including tree conflict data) are written to
> disk at the same time, in a single call to svn_wc__entries_write().

The point being whether other loggy commands may depend on some
tree-conflicts already being recorded when they are run. Adding them up in
memory to only write them at the end would break such a dependency.

Are you *sure* that it's not a problem? Maybe it *will* be a problem some
time? I suggest performing an svn_wc__entries_write() after each loggy
add-tree-conflict command. It's safer, right?

~Neels

Received on 2008-12-02 04:24:47 CET

This is an archived mail posted to the Subversion Dev mailing list.