RE: svn commit: r1657846 - in /subversion/trunk/subversion/libsvn_wc: wc-queries.sql wc_db.c wc_db.h wc_db_private.h wc_db_update_move.c

> -----Original Message-----
> From: Branko Čibej [mailto:brane_at_wandisco.com]
> Sent: vrijdag 6 februari 2015 15:58
> To: dev_at_subversion.apache.org
> Subject: Re: svn commit: r1657846 - in /subversion/trunk/subversion/libsvn_wc:
> wc-queries.sql wc_db.c wc_db.h wc_db_private.h wc_db_update_move.c
>
> On 06.02.2015 15:46, rhuijben_at_apache.org wrote:
> > Author: rhuijben
> > Date: Fri Feb 6 14:46:49 2015
> > New Revision: 1657846
> >
> > URL: http://svn.apache.org/r1657846
> > Log:
> > Instead of transforming nodes into an copy by changing their op-depth make
> > a proper copy, to allow the layer bump code to handle further edge cases
> > like things that are recorded while shadowing.
>
>
> How will this affect working copy compatibility? Will 1.8.x, when seeing
> a trunk WC with such records in it, know what to do about them?

This is just an intermediate state that doesn't exist outside the sqlite transaction that we run the code in.

The previous intermediate state, could (when the transaction would be stopped halfway) cause some differences between the working copy and the repository. While the new code keeps the database valid.

But as noted: all this is inside a transaction, so if something fails it is not committed.

The problem with the old code is that we had all kinds of bad intermediate states, which some other code at a later stage (mostly accidentally) fixed. I'm trying to keep things in logical operations now, that could be performed by itself (outside the global move-update) transaction, without leaving the database inconsistent.

And as it is just WC state, 1.8 (and in theory 1.7) could just handle this intermediate state. (The previous intermediate state would give an out of date on commit as the lower layer wasn't deleted)

        Bert
Received on 2015-02-06 16:50:29 CET