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

Re: Tree-conflicts: HEADS UP: update failure with tc-siblings :0

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 17 Nov 2008 16:29:55 +0000

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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.