[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: Stephen Butler <sbutler_at_elego.de>
Date: Mon, 17 Nov 2008 14:18:42 +0100

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.
> The tests happen to work because no test kills the processes randomly
> to see if it can leave the WC in an inconsistent state.
> Please revert your change, and in the future keep in mind the integrity
> of the metadata at each point in time.

Reverted r34235 in r34238.

> On Nov 16, 2008, at 19:48, "Neels J. Hofmeyr" <neels_at_elego.de> wrote:
>> Stephen Butler wrote:
>>> Instead of keeping conflict structs in memory until the parent dir is
>>> closed, why don't we write each tree conflict immediately? That would
>>> eliminate the possibility of lost conflicts on cancel.

Whoops, bad idea!

>> I wonder though if there could be any problem with the tree-conflicts being
>> recorded immediately and all the other node changes stored in the log being
>> made only later on.

Too true.

>> I think the "best" fix of this would be to have a new log command, as in
>> <entry-add-tree-conflict data="B:dir:..."/>. Are there any interface reasons
>> preventing that?

I think that's kosher. The log execution functions are static, so I'm
creating log_do_add_tree_conflict() to implement this new command.


Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
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 14:18:57 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.