You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by ju...@apache.org on 2010/09/27 13:58:18 UTC
svn propchange: r1001678 - svn:log
Author: julianfoad
Revision: 1001678
Modified property: svn:log
Modified: svn:log at Mon Sep 27 11:58:18 2010
------------------------------------------------------------------------------
--- svn:log (original)
+++ svn:log Mon Sep 27 11:58:18 2010
@@ -1,2 +1,12 @@
+Guard some ongoing op_depth work inside a new conditional: SVN_WC__OP_DEPTH.
+Guards the change made in r1000557, but not yet the similar changes made in
+r1000955. These op_depth changes are causing test failures, and the fixes
+are expected to be extensive.
+
+Also document an existing function.
+
* subversion/libsvn_wc/wc_db.c
(construct_like_arg): Add a doc string. Fix naming of the pool arg.
+ (svn_wc__db_op_add_directory, svn_wc__db_op_add_file,
+ svn_wc__db_op_add_symlink): Change op_depth back to a hard-coded '2'
+ unless SVN_WC__OP_DEPTH is defined.
Re: svn propchange: r1001678 - svn:log
Posted by Philip Martin <ph...@wandisco.com>.
Julian Foad <ju...@wandisco.com> writes:
> Greg Stein wrote:
>> Why are tests failing because of the different values?
>
> I think it's not because the op_depth value is different, but because
> creating a row with a different op_depth now in some cases means
> creating an *additional* row, and the rest of the code is not yet
> prepared for finding two or more WORKING rows for the same node.
> Something like that.
A typical failure was a delete followed by an add/replace. The delete
creates a row with op_depth=2 (a temporary value) and the add creates
a row with op_depth=1 (a correct value). When we select the row with
the highest op_depth we don't see the add.
We had a brief discussion on IRC about this. The add does an INSERT
OR REPLACE and the op_depth difference makes it an insert rather than
a replace. Should add determine whether it should insert or replace
and make the appropriate query? The temporary op_depth values lead to
a corrupt database if the op_depth values are assummed to be correct.
Should add detect the corruption?
--
Philip
Re: svn propchange: r1001678 - svn:log
Posted by Julian Foad <ju...@wandisco.com>.
Greg Stein wrote:
> Why are tests failing because of the different values?
I think it's not because the op_depth value is different, but because
creating a row with a different op_depth now in some cases means
creating an *additional* row, and the rest of the code is not yet
prepared for finding two or more WORKING rows for the same node.
Something like that.
- Julian
> Philip stated that we weren't really examining the values. That "zero
> vs non-zero" was the only real test so far. So why does inserting
> other values break things? That seems to be a more interesting problem
> to solve than simply throwing up our collective hands and #ifdef'ing
> the values out (along with that additional complexity!)
>
> Cheers,
> -g
>
> On Mon, Sep 27, 2010 at 07:58, <ju...@apache.org> wrote:
> > Author: julianfoad
> > Revision: 1001678
> > Modified property: svn:log
> >
> > Modified: svn:log at Mon Sep 27 11:58:18 2010
> > ------------------------------------------------------------------------------
> > --- svn:log (original)
> > +++ svn:log Mon Sep 27 11:58:18 2010
> > @@ -1,2 +1,12 @@
> > +Guard some ongoing op_depth work inside a new conditional: SVN_WC__OP_DEPTH.
> > +Guards the change made in r1000557, but not yet the similar changes made in
> > +r1000955. These op_depth changes are causing test failures, and the fixes
> > +are expected to be extensive.
> > +
> > +Also document an existing function.
> > +
> > * subversion/libsvn_wc/wc_db.c
> > (construct_like_arg): Add a doc string. Fix naming of the pool arg.
> > + (svn_wc__db_op_add_directory, svn_wc__db_op_add_file,
> > + svn_wc__db_op_add_symlink): Change op_depth back to a hard-coded '2'
> > + unless SVN_WC__OP_DEPTH is defined.
> >
> >
Re: svn propchange: r1001678 - svn:log
Posted by Greg Stein <gs...@gmail.com>.
Why are tests failing because of the different values?
Philip stated that we weren't really examining the values. That "zero
vs non-zero" was the only real test so far. So why does inserting
other values break things? That seems to be a more interesting problem
to solve than simply throwing up our collective hands and #ifdef'ing
the values out (along with that additional complexity!)
Cheers,
-g
On Mon, Sep 27, 2010 at 07:58, <ju...@apache.org> wrote:
> Author: julianfoad
> Revision: 1001678
> Modified property: svn:log
>
> Modified: svn:log at Mon Sep 27 11:58:18 2010
> ------------------------------------------------------------------------------
> --- svn:log (original)
> +++ svn:log Mon Sep 27 11:58:18 2010
> @@ -1,2 +1,12 @@
> +Guard some ongoing op_depth work inside a new conditional: SVN_WC__OP_DEPTH.
> +Guards the change made in r1000557, but not yet the similar changes made in
> +r1000955. These op_depth changes are causing test failures, and the fixes
> +are expected to be extensive.
> +
> +Also document an existing function.
> +
> * subversion/libsvn_wc/wc_db.c
> (construct_like_arg): Add a doc string. Fix naming of the pool arg.
> + (svn_wc__db_op_add_directory, svn_wc__db_op_add_file,
> + svn_wc__db_op_add_symlink): Change op_depth back to a hard-coded '2'
> + unless SVN_WC__OP_DEPTH is defined.
>
>