On Mon, 2008-11-17 at 17:01 +0100, Stephen Butler wrote:
> 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.
Ah, that sounds plausible.
> 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()).
OK, that has a certain logic to it.
> 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.
Yes, I see that that would be better. OK, please do, thanks!
> > 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.
I hope so.
Do you agree that the functions svn_wc__add/del_tree_conflict, as
currently implemented, are bad and should go away (because they take an
existing adm_access baton and return with it out of sync)?
- 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:30:29 CET