You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2009/05/15 17:21:23 UTC
Neon test failures explained.
I think I've *finally* determined that the remaining Neon test failures are,
once again, related to wcprops. But this time, it's not the new wcprops
code that really takes the blame here.
Here's a simple test script (which expects that ~/.subversion/servers
demands Neon):
------------------------------------------------------------------------
#!/bin/sh
set -x
rm -rf repos wc
svnadmin create repos
svn co http://localhost/tests/repos wc
(cd wc; make-greek-tree .)
svn ci -m "" wc
svn up wc
svn pset foo bar wc
svn ci -m "" wc
svn up -r1 wc
svn pset foo eek wc
### Uncomment this line to see Total Failure
#find wc -name all-wcprops | xargs rm
echo "### The following commit should fail do to out-of-dateness. ###"
svn ci -m "" wc
------------------------------------------------------------------------
As-is, the test does what is expected. But if you uncomment the line that
purges the wcprops from the working copy, the final commit does not detect
its out-of-dateness. This is a bug in Neon, period. The DAV RA layers are
expected to be resilient in the face of a missing DAV cache, which only
exists for performance reasons.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2272935
Re: Neon test failures explained.
Posted by "C. Michael Pilato" <cm...@collab.net>.
Now, a follow-up. Unless I'm mistaken, something about the new codebase
seems to be causing no wcprops to be stored in the working copy. *That's* a
bug in the new wcprop logic, and one that needs to be fixed.
Fortunately, it seems (in IRC) that at least Hyrum already knew about this
problem.
C. Michael Pilato wrote:
> I think I've *finally* determined that the remaining Neon test failures are,
> once again, related to wcprops. But this time, it's not the new wcprops
> code that really takes the blame here.
>
> Here's a simple test script (which expects that ~/.subversion/servers
> demands Neon):
>
> ------------------------------------------------------------------------
> #!/bin/sh
> set -x
> rm -rf repos wc
> svnadmin create repos
> svn co http://localhost/tests/repos wc
> (cd wc; make-greek-tree .)
> svn ci -m "" wc
> svn up wc
> svn pset foo bar wc
> svn ci -m "" wc
> svn up -r1 wc
> svn pset foo eek wc
>
> ### Uncomment this line to see Total Failure
> #find wc -name all-wcprops | xargs rm
>
> echo "### The following commit should fail do to out-of-dateness. ###"
> svn ci -m "" wc
> ------------------------------------------------------------------------
>
> As-is, the test does what is expected. But if you uncomment the line that
> purges the wcprops from the working copy, the final commit does not detect
> its out-of-dateness. This is a bug in Neon, period. The DAV RA layers are
> expected to be resilient in the face of a missing DAV cache, which only
> exists for performance reasons.
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2273482
Re: Neon test failures explained.
Posted by "C. Michael Pilato" <cm...@collab.net>.
C. Michael Pilato wrote:
> I think I've *finally* determined that the remaining Neon test failures are,
> once again, related to wcprops. But this time, it's not the new wcprops
> code that really takes the blame here.
$ svn blame subversion/libsvn_ra_neon/commit.c
[...]
492 kfogel static svn_error_t * commit_open_root(void *edit_baton,
1396 gstein svn_revnum_t
base_revision,
1396 gstein apr_pool_t *dir_pool,
492 kfogel void **root_baton)
1 svn {
1 svn commit_ctx_t *cc = edit_baton;
1 svn resource_baton_t *root;
17262 dionisos version_rsrc_t *rsrc;
1 svn
7371 cmpilato /* create the root resource. no wr_url (yet). */
7371 cmpilato rsrc = apr_pcalloc(dir_pool, sizeof(*rsrc));
7371 cmpilato rsrc->pool = dir_pool;
1863 gstein
1863 gstein /* ### should this be 'base_revision' here? we might not
always be
1863 gstein ### working against the head! (think "properties"). */
1863 gstein rsrc->revision = SVN_INVALID_REVNUM;
Methinks, Greg, that the answer is "yes". And thanks to wcprops, methinks
we've been able to avoid doing the right thing here for **YEARS**.
Testing that theory now.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2273657