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.
Cheers
-g
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.
>
> And it would make the fix a lot simpler. If the code turns out to be
> too
> slow, we can still add the bunching together later on. Going the
> simpler way
> is better at this time.
>
> 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.
>
> 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?
>
> We could also set the tree-conflict data on the *victim* when
> writing to the
> log, and append victims' tree-conflict data to their respective
> parents
> during log replay...
>
> I have implemented the simple fix (write tree-conflicts immediately)
> quicker
> than writing this mail and it seems to cause no new test failures.
> So I'm
> committing that, while above alternatives remain open.
>
> Thanks!
> ~Neels
>
>
---------------------------------------------------------------------
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 11:00:11 CET