locking problems

[Greg Stein <gs...@gmail.com>]

Hey all,

Just now, I was running the full test suite. While that was running
the background, I started a commit from the libsvn_wc directory.

Two problems:

1) subversion/... was locked. not just libsvn_wc

2) the test suite broke because it saw a lock down in tests/cmdline


I think (1) is kind of normal; I'm not sure. The latter is
problematic. It reported a lock on
svn-test-work/working-copies/basic_tests-48. That should not have been
there!

I'm wondering if (somehow), the system is skip up from basic_tests-48/
all the way to tests/cmdline. Seeing the depth=infinity lock there,
and applying it to the test?

It seems plausible, but also highly problematic :-(

Anyone?

Cheers,
-g

Re: BUG: WC-NG code crawls too high to find WC root

["C. Michael Pilato" <cm...@collab.net>]

C. Michael Pilato wrote:
> C. Michael Pilato wrote:
>> From time to time, I've seen evidence that our trunk code is walking up too
>> far in its parent tree as well, but every time I try to create a reliable
>> recipe, I can't.  I have nothing but wc-1 working copies on my system for
>> day-to-day use.  (I run subversion 1.6.x by default.)  My home directory is
>> versioned, for example, as is the directory ~/tests (but nothing inside
>> ~/tests is versioned).  What I've seen, though, is that if I use trunk svn
>> to do some testing, creating working copies and such inside ~/test/,
>> sometimes I get errors that indicate that the client has crawled up out of
>> that wc-ng working copy and is looking at ~/test/.  Obviously, it'd be fine
>> if it crawled up that far, realized that it had gone above the WC root, and
>> just gracefully realized that it had crawled too far.  But instead, it fails
>> with an error.  Unfortunately, I can't recall which error is presented:
>> "working copy is too old", perhaps.

(Just to close off this thread) I fixed this bug myself in r956119 by adding
a new macro which combines the check for SVN_ERR_WC_NOT_WORKING_COPY and
SVN_ERR_WC_UPGRADE_REQUIRED, and then made use of the macro in many places
where the former of those errors was checked.  Don't worry -- Subversion
still tells you if you try to operate directly on a pre-1.7 working copy
that you need to upgrade.  But crawls up the parent chain now stop where
they used to (and should):  at the first directory that's not a (valid)
working copy.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

BUG: WC-NG code crawls too high to find WC root (was: "Re: locking problems")

["C. Michael Pilato" <cm...@collab.net>]

C. Michael Pilato wrote:
> From time to time, I've seen evidence that our trunk code is walking up too
> far in its parent tree as well, but every time I try to create a reliable
> recipe, I can't.  I have nothing but wc-1 working copies on my system for
> day-to-day use.  (I run subversion 1.6.x by default.)  My home directory is
> versioned, for example, as is the directory ~/tests (but nothing inside
> ~/tests is versioned).  What I've seen, though, is that if I use trunk svn
> to do some testing, creating working copies and such inside ~/test/,
> sometimes I get errors that indicate that the client has crawled up out of
> that wc-ng working copy and is looking at ~/test/.  Obviously, it'd be fine
> if it crawled up that far, realized that it had gone above the WC root, and
> just gracefully realized that it had crawled too far.  But instead, it fails
> with an error.  Unfortunately, I can't recall which error is presented:
> "working copy is too old", perhaps.

Here's a recipe for this problem.

------------------------------------------------------------
#!/bin/sh

OLD_SVN=/home/cmpilato/projects/subversion/branches/1.6.x/subversion/svn/svn
OLD_SVNADMIN=/home/cmpilato/projects/subversion/branches/1.6.x/subversion/svnadmin/svnadmin
SVN17=/home/cmpilato/projects/subversion/trunk/subversion/svn/svn

echo "### Remove junk from previous test runs."
rm -rf crawl-too-high
mkdir crawl-too-high

echo "### Create a couple of repositories to play with."
${OLD_SVNADMIN} create crawl-too-high/repos1
${OLD_SVNADMIN} create crawl-too-high/repos2

echo "### Checkout the first repository using a pre-1.7 client."
${OLD_SVN} co file://`pwd`/crawl-too-high/repos1 crawl-too-high/wc

echo "### Commit the addition of a subdirectory into the repository."
${OLD_SVN} mkdir crawl-too-high/wc/subdir
${OLD_SVN} ci -m "Create a subdirectory." crawl-too-high/wc

echo "### Now checkout the second repository again, this time using"
echo "### Subversion 1.7, into the subdir of the pre-1.7 working copy."
${SVN17} co file://`pwd`/crawl-too-high/repos2 crawl-too-high/wc/subdir

-----------------------------------------------------------

And here's what I see today when I run it:

### Remove junk from previous test runs.
### Create a couple of repositories to play with.
### Checkout the first repository using a pre-1.7 client.
Checked out revision 0.
### Commit the addition of a subdirectory into the repository.
A         crawl-too-high/wc/subdir
Adding         crawl-too-high/wc/subdir

Committed revision 1.
### Now checkout the second repository again, this time using
### Subversion 1.7, into the subdir of the pre-1.7 working copy.
subversion/svn/checkout-cmd.c:173: (apr_err=155036)
subversion/libsvn_client/checkout.c:168: (apr_err=155036)
subversion/libsvn_wc/lock.c:123: (apr_err=155036)
subversion/libsvn_wc/lock.c:123: (apr_err=155036)
subversion/libsvn_wc/wc_db.c:5450: (apr_err=155036)
subversion/libsvn_wc/wc_db.c:1073: (apr_err=155036)
subversion/libsvn_wc/wc_db.c:425: (apr_err=155036)
subversion/libsvn_wc/upgrade.c:1083: (apr_err=155036)
svn: Working copy format of '/home/cmpilato/tests/crawl-too-high/wc/subdir'
is too old (10); please run 'svn upgrade'


-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: locking problems

["C. Michael Pilato" <cm...@collab.net>]

Greg Stein wrote:
> Hey all,
> 
> Just now, I was running the full test suite. While that was running
> the background, I started a commit from the libsvn_wc directory.
> 
> Two problems:
> 
> 1) subversion/... was locked. not just libsvn_wc
> 
> 2) the test suite broke because it saw a lock down in tests/cmdline
> 
> 
> I think (1) is kind of normal; I'm not sure. The latter is
> problematic. It reported a lock on
> svn-test-work/working-copies/basic_tests-48. That should not have been
> there!
> 
> I'm wondering if (somehow), the system is skip up from basic_tests-48/
> all the way to tests/cmdline. Seeing the depth=infinity lock there,
> and applying it to the test?
> 
> It seems plausible, but also highly problematic :-(
> 
> Anyone?

From time to time, I've seen evidence that our trunk code is walking up too
far in its parent tree as well, but every time I try to create a reliable
recipe, I can't.  I have nothing but wc-1 working copies on my system for
day-to-day use.  (I run subversion 1.6.x by default.)  My home directory is
versioned, for example, as is the directory ~/tests (but nothing inside
~/tests is versioned).  What I've seen, though, is that if I use trunk svn
to do some testing, creating working copies and such inside ~/test/,
sometimes I get errors that indicate that the client has crawled up out of
that wc-ng working copy and is looking at ~/test/.  Obviously, it'd be fine
if it crawled up that far, realized that it had gone above the WC root, and
just gracefully realized that it had crawled too far.  But instead, it fails
with an error.  Unfortunately, I can't recall which error is presented:
"working copy is too old", perhaps.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand