You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@wandisco.com> on 2015/02/06 15:57:46 UTC
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@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?
-- Brane
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
Posted by Branko Čibej <br...@wandisco.com>.
On 06.02.2015 16:48, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: Branko Čibej [mailto:brane@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, rhuijben@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.
Thanks; that wasn't too obvious from the diff or log message.
-- Brane
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
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Branko Čibej [mailto:brane@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, rhuijben@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