> -----Original Message-----
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: vrijdag 6 februari 2015 15:58
> To: dev@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, rhuij...@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
