You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Sebastian Bergmann <sb...@sebastian-bergmann.de> on 2002/12/15 18:04:47 UTC
Obstructed update
Hi.
I made a fresh checkout of subversion
svn co http://svn.collab.net/repos/svn/trunk subversion
but "svn up" fails with
sb@wopr-mobile:/usr/src/subversion> svn up
svn: Obstructed update
svn: The entry 'ac-helpers' is no longer a directory,
which prevents proper updates.
Please remove this entry and try updating again.
Removing 'ac-helpers' doesn't solve this, as subversion will then
complaing about the next directory, and so forth.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: WC Weirdness
Posted by Ben Collins-Sussman <su...@collab.net>.
Jeffrey Melloy <jm...@visualdistortion.org> writes:
> a week or so ago, I noticed in "svn st" produced some weird output.
> S hw/digital/hw/assign-a/Behavioral Design.vhd
> S hw/digital/hw/assign-a/Structural Design.vhd
> S web/compsupp/StaffPages/shell1 copy.jpg
> S web/rookery/Headline/Picture 2
> S web/rookery/Headline/The Rookery 2
> S web/rookery/Headline/The Rookery.tiff
> S web/rookery/not my grpahis
> Now, none of these files had been updated in a while (especially the
> web stuff), and I hadn't set "svn switch" on any of them. Figuring
> I'd take care of it later, I left it alone.
The 'S' means that the entry's url isn't a proper child of its
parent's entry's url. In other words, the child url can't be created
by simply slapping the basename onto the parent's url.
Try running 'svn info' on both the parent and child, and see what urls
are recorded for them.
> Today, when I tried to do "svn st -u", it timed out connecting to my
> repository. Same if I did svn up. Same if I committed [...]
Sounds like one of the urls is unreachable. What are they?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
WC Weirdness
Posted by Jeffrey Melloy <jm...@visualdistortion.org>.
a week or so ago, I noticed in "svn st" produced some weird output.
S hw/digital/hw/assign-a/Behavioral Design.vhd
S hw/digital/hw/assign-a/Structural Design.vhd
S web/compsupp/StaffPages/shell1 copy.jpg
S web/rookery/Headline/Picture 2
S web/rookery/Headline/The Rookery 2
S web/rookery/Headline/The Rookery.tiff
S web/rookery/not my grpahis
Now, none of these files had been updated in a while (especially the
web stuff), and I hadn't set "svn switch" on any of them. Figuring I'd
take care of it later, I left it alone.
Today, when I tried to do "svn st -u", it timed out connecting to my
repository. Same if I did svn up. Same if I committed, (I tried
twice, once with wireless, once wired, and the same thing happened, but
one seemed to go through, oddly) Connecting to a different repository
hosted on the same machine didn't have any problems. Checkout works
fine.
Any help would be appreciated.
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by Philip Martin <ph...@codematters.co.uk>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> Committed a patch to ignore the
> results of d_type when it's DT_UNKNOWN (or a code we don't grok)
> and ignore the results of d_fileno/d_ino when the value is 0 or -1.
That works for me :)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
As much as I agree 0 might be a valid inode... I strongly suspect
that 0 would be reserved for the boot sector or other filesystem
tables. I'm not too worried that 0 is a valid file of anything other than
'/'
Bill
At 07:19 PM 12/18/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>William A. Rowe, Jr. wrote:
>
>>At 11:48 AM 12/18/2002, William A. Rowe, Jr. wrote:
>>
>>
>>>At 08:14 AM 12/18/2002, Philip Martin wrote:
>>>
>>>
>>>>This is for dir.c version 1.71 with the patch reverted. The
>>>>Subversion code is svn_io_get_dirents in subversion/libsvn_subr/io.c,
>>>>it passes APR_FINFO_TYPE | APR_FINFO_NAME to apr_dir_read. The first
>>>>two calls to apr_dir_read return "." and ".." and the Subversion code
>>>>skips them, the following gdb information is for the third call
>>>>
>>>>
>>
>>,,, never mind my earlier questions. Committed a patch to ignore the
>>results of d_type when it's DT_UNKNOWN (or a code we don't grok)
>>and ignore the results of d_fileno/d_ino when the value is 0 or -1.
>>
>>
>Yes, I'd figured on something like that being the correct fix. But I'm
>not sure what to use as an invalid inode number; -1 almost certainly,
>but I have a horrible suspicion that 0 might be a valid inode.
>
>--
>Brane Äibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
As much as I agree 0 might be a valid inode... I strongly suspect
that 0 would be reserved for the boot sector or other filesystem
tables. I'm not too worried that 0 is a valid file of anything other than
'/'
Bill
At 07:19 PM 12/18/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>William A. Rowe, Jr. wrote:
>
>>At 11:48 AM 12/18/2002, William A. Rowe, Jr. wrote:
>>
>>
>>>At 08:14 AM 12/18/2002, Philip Martin wrote:
>>>
>>>
>>>>This is for dir.c version 1.71 with the patch reverted. The
>>>>Subversion code is svn_io_get_dirents in subversion/libsvn_subr/io.c,
>>>>it passes APR_FINFO_TYPE | APR_FINFO_NAME to apr_dir_read. The first
>>>>two calls to apr_dir_read return "." and ".." and the Subversion code
>>>>skips them, the following gdb information is for the third call
>>>>
>>>>
>>
>>,,, never mind my earlier questions. Committed a patch to ignore the
>>results of d_type when it's DT_UNKNOWN (or a code we don't grok)
>>and ignore the results of d_fileno/d_ino when the value is 0 or -1.
>>
>>
>Yes, I'd figured on something like that being the correct fix. But I'm
>not sure what to use as an invalid inode number; -1 almost certainly,
>but I have a horrible suspicion that 0 might be a valid inode.
>
>--
>Brane Äibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:
>At 11:48 AM 12/18/2002, William A. Rowe, Jr. wrote:
>
>
>>At 08:14 AM 12/18/2002, Philip Martin wrote:
>>
>>
>>>This is for dir.c version 1.71 with the patch reverted. The
>>>Subversion code is svn_io_get_dirents in subversion/libsvn_subr/io.c,
>>>it passes APR_FINFO_TYPE | APR_FINFO_NAME to apr_dir_read. The first
>>>two calls to apr_dir_read return "." and ".." and the Subversion code
>>>skips them, the following gdb information is for the third call
>>>
>>>
>
>,,, never mind my earlier questions. Committed a patch to ignore the
>results of d_type when it's DT_UNKNOWN (or a code we don't grok)
>and ignore the results of d_fileno/d_ino when the value is 0 or -1.
>
>
Yes, I'd figured on something like that being the correct fix. But I'm
not sure what to use as an invalid inode number; -1 almost certainly,
but I have a horrible suspicion that 0 might be a valid inode.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:
>At 11:48 AM 12/18/2002, William A. Rowe, Jr. wrote:
>
>
>>At 08:14 AM 12/18/2002, Philip Martin wrote:
>>
>>
>>>This is for dir.c version 1.71 with the patch reverted. The
>>>Subversion code is svn_io_get_dirents in subversion/libsvn_subr/io.c,
>>>it passes APR_FINFO_TYPE | APR_FINFO_NAME to apr_dir_read. The first
>>>two calls to apr_dir_read return "." and ".." and the Subversion code
>>>skips them, the following gdb information is for the third call
>>>
>>>
>
>,,, never mind my earlier questions. Committed a patch to ignore the
>results of d_type when it's DT_UNKNOWN (or a code we don't grok)
>and ignore the results of d_fileno/d_ino when the value is 0 or -1.
>
>
Yes, I'd figured on something like that being the correct fix. But I'm
not sure what to use as an invalid inode number; -1 almost certainly,
but I have a horrible suspicion that 0 might be a valid inode.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:48 AM 12/18/2002, William A. Rowe, Jr. wrote:
>At 08:14 AM 12/18/2002, Philip Martin wrote:
>>
>>This is for dir.c version 1.71 with the patch reverted. The
>>Subversion code is svn_io_get_dirents in subversion/libsvn_subr/io.c,
>>it passes APR_FINFO_TYPE | APR_FINFO_NAME to apr_dir_read. The first
>>two calls to apr_dir_read return "." and ".." and the Subversion code
>>skips them, the following gdb information is for the third call
,,, never mind my earlier questions. Committed a patch to ignore the
results of d_type when it's DT_UNKNOWN (or a code we don't grok)
and ignore the results of d_fileno/d_ino when the value is 0 or -1.
Bill
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by Philip Martin <ph...@codematters.co.uk>.
"William A. Rowe, Jr." <wr...@apache.org> writes:
> Philip... thanks.
>
> Now for the oddball question, looking at dirent.h or it's associate sys/
> includes, what symbol DT_xxx (DT_REG, etc) do you find for value 0?
/usr/include/dirent.h
/* File types for `d_type'. */
enum
{
DT_UNKNOWN = 0,
# define DT_UNKNOWN DT_UNKNOWN
DT_FIFO = 1,
# define DT_FIFO DT_FIFO
DT_CHR = 2,
# define DT_CHR DT_CHR
DT_DIR = 4,
# define DT_DIR DT_DIR
DT_BLK = 6,
# define DT_BLK DT_BLK
DT_REG = 8,
# define DT_REG DT_REG
DT_LNK = 10,
# define DT_LNK DT_LNK
DT_SOCK = 12,
# define DT_SOCK DT_SOCK
DT_WHT = 14
# define DT_WHT DT_WHT
};
> Also, what values do you have for DIRENT_TYPE, DIRENT_INODE from
> apr/include/arch/unix/apr_private.h?
#define DIRENT_INODE d_fileno
#define DIRENT_TYPE d_type
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by Philip Martin <ph...@codematters.co.uk>.
"William A. Rowe, Jr." <wr...@apache.org> writes:
> Philip... thanks.
>
> Now for the oddball question, looking at dirent.h or it's associate sys/
> includes, what symbol DT_xxx (DT_REG, etc) do you find for value 0?
/usr/include/dirent.h
/* File types for `d_type'. */
enum
{
DT_UNKNOWN = 0,
# define DT_UNKNOWN DT_UNKNOWN
DT_FIFO = 1,
# define DT_FIFO DT_FIFO
DT_CHR = 2,
# define DT_CHR DT_CHR
DT_DIR = 4,
# define DT_DIR DT_DIR
DT_BLK = 6,
# define DT_BLK DT_BLK
DT_REG = 8,
# define DT_REG DT_REG
DT_LNK = 10,
# define DT_LNK DT_LNK
DT_SOCK = 12,
# define DT_SOCK DT_SOCK
DT_WHT = 14
# define DT_WHT DT_WHT
};
> Also, what values do you have for DIRENT_TYPE, DIRENT_INODE from
> apr/include/arch/unix/apr_private.h?
#define DIRENT_INODE d_fileno
#define DIRENT_TYPE d_type
>From the libc info files:
`unsigned char d_type'
This is the type of the file, possibly unknown. The
following constants are defined for its value:
`DT_UNKNOWN'
The type is unknown. On some systems this is the only
value returned.
A test program:
$ cat z.c
#include <dirent.h>
#include <sys/types.h>
int main() {
DIR *d = opendir(".");
struct dirent e, *r;
int v = readdir_r(d, &e, &r);
while (! v && r) {
printf("%s %d\n", r->d_name, r->d_type);
v = readdir_r(d, &e, &r);
}
return 0;
}
$ gcc -o z z.c
$ ls -l
total 13
drwxr-sr-x 2 pm pm 48 Dec 18 18:21 foo
-rwxr-xr-x 1 pm pm 5147 Dec 18 18:22 z
-rw-r--r-- 1 pm pm 262 Dec 18 18:22 z.c
$ ./z
. 0
.. 0
z 0
foo 0
z.c 0
--
Philip Martin
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:48 AM 12/18/2002, William A. Rowe, Jr. wrote:
>At 08:14 AM 12/18/2002, Philip Martin wrote:
>>
>>This is for dir.c version 1.71 with the patch reverted. The
>>Subversion code is svn_io_get_dirents in subversion/libsvn_subr/io.c,
>>it passes APR_FINFO_TYPE | APR_FINFO_NAME to apr_dir_read. The first
>>two calls to apr_dir_read return "." and ".." and the Subversion code
>>skips them, the following gdb information is for the third call
,,, never mind my earlier questions. Committed a patch to ignore the
results of d_type when it's DT_UNKNOWN (or a code we don't grok)
and ignore the results of d_fileno/d_ino when the value is 0 or -1.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 08:14 AM 12/18/2002, Philip Martin wrote:
>"William A. Rowe, Jr." <wr...@apache.org> writes:
>
>> What I would like to know (if you can track it...)
>>
>> Is it possible to dump the finfo structure within gdb at the point this
>> request fails? I'd pay especially close attention to the .valid bits, since
>> those are the identifiers that will help us determine if stat() was also
>> called later.
>
>This is for dir.c version 1.71 with the patch reverted. The
>Subversion code is svn_io_get_dirents in subversion/libsvn_subr/io.c,
>it passes APR_FINFO_TYPE | APR_FINFO_NAME to apr_dir_read. The first
>two calls to apr_dir_read return "." and ".." and the Subversion code
>skips them, the following gdb information is for the third call
>
>(gdb) s
>apr_dir_read (finfo=0xbffff660, wanted=33587200, thedir=0x809a878) at dir.c:174
>174 apr_status_t ret = 0;
>(gdb) n
>179 ret = readdir_r(thedir->dirstruct, thedir->entry, &retent);
>(gdb)
>184 if(!ret && thedir->entry != retent)
>(gdb) p ret
>$1 = 0
>(gdb) p thedir->entry[0]
>$2 = {d_ino = 186434, d_off = 13512064, d_reclen = 16, d_type = 0 '\0',
> d_name = "..", '\0' <repeats 253 times>}
Philip... thanks.
Now for the oddball question, looking at dirent.h or it's associate sys/
includes, what symbol DT_xxx (DT_REG, etc) do you find for value 0?
Also, what values do you have for DIRENT_TYPE, DIRENT_INODE from
apr/include/arch/unix/apr_private.h?
Thanks again,
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 08:14 AM 12/18/2002, Philip Martin wrote:
>"William A. Rowe, Jr." <wr...@apache.org> writes:
>
>> What I would like to know (if you can track it...)
>>
>> Is it possible to dump the finfo structure within gdb at the point this
>> request fails? I'd pay especially close attention to the .valid bits, since
>> those are the identifiers that will help us determine if stat() was also
>> called later.
>
>This is for dir.c version 1.71 with the patch reverted. The
>Subversion code is svn_io_get_dirents in subversion/libsvn_subr/io.c,
>it passes APR_FINFO_TYPE | APR_FINFO_NAME to apr_dir_read. The first
>two calls to apr_dir_read return "." and ".." and the Subversion code
>skips them, the following gdb information is for the third call
>
>(gdb) s
>apr_dir_read (finfo=0xbffff660, wanted=33587200, thedir=0x809a878) at dir.c:174
>174 apr_status_t ret = 0;
>(gdb) n
>179 ret = readdir_r(thedir->dirstruct, thedir->entry, &retent);
>(gdb)
>184 if(!ret && thedir->entry != retent)
>(gdb) p ret
>$1 = 0
>(gdb) p thedir->entry[0]
>$2 = {d_ino = 186434, d_off = 13512064, d_reclen = 16, d_type = 0 '\0',
> d_name = "..", '\0' <repeats 253 times>}
Philip... thanks.
Now for the oddball question, looking at dirent.h or it's associate sys/
includes, what symbol DT_xxx (DT_REG, etc) do you find for value 0?
Also, what values do you have for DIRENT_TYPE, DIRENT_INODE from
apr/include/arch/unix/apr_private.h?
Thanks again,
Bill
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by Philip Martin <ph...@codematters.co.uk>.
"William A. Rowe, Jr." <wr...@apache.org> writes:
> What I would like to know (if you can track it...)
>
> Is it possible to dump the finfo structure within gdb at the point this
> request fails? I'd pay especially close attention to the .valid bits, since
> those are the identifiers that will help us determine if stat() was also
> called later.
This is for dir.c version 1.71 with the patch reverted. The
Subversion code is svn_io_get_dirents in subversion/libsvn_subr/io.c,
it passes APR_FINFO_TYPE | APR_FINFO_NAME to apr_dir_read. The first
two calls to apr_dir_read return "." and ".." and the Subversion code
skips them, the following gdb information is for the third call
(gdb) s
apr_dir_read (finfo=0xbffff660, wanted=33587200, thedir=0x809a878) at dir.c:174
174 apr_status_t ret = 0;
(gdb) n
179 ret = readdir_r(thedir->dirstruct, thedir->entry, &retent);
(gdb)
184 if(!ret && thedir->entry != retent)
(gdb) p ret
$1 = 0
(gdb) p thedir->entry[0]
$2 = {d_ino = 186434, d_off = 13512064, d_reclen = 16, d_type = 0 '\0',
d_name = "..", '\0' <repeats 253 times>}
(gdb) n
194 if (ret == EINVAL) {
(gdb)
214 finfo->fname = NULL;
(gdb)
216 if (ret) {
(gdb)
222 wanted &= ~APR_FINFO_INODE;
(gdb) p/x wanted
$3 = 0x2008000
(gdb) n
225 wanted &= ~APR_FINFO_TYPE;
(gdb)
228 wanted &= ~APR_FINFO_NAME;
(gdb)
230 if (wanted)
(gdb) p wanted
$4 = 0
(gdb) n
244 if (wanted && (ret == APR_SUCCESS || ret == APR_INCOMPLETE)) {
(gdb)
251 finfo->pool = thedir->pool;
(gdb)
252 finfo->valid = 0;
(gdb)
254 finfo->filetype = filetype_from_dirent_type(thedir->entry->DIRENT_TYPE);
(gdb)
255 finfo->valid |= APR_FINFO_TYPE;
(gdb) p finfo->filetype
$5 = APR_UNKFILE
(gdb) n
258 finfo->inode = thedir->entry->DIRENT_INODE;
(gdb)
259 finfo->valid |= APR_FINFO_INODE;
(gdb)
263 finfo->name = apr_pstrdup(thedir->pool, thedir->entry->d_name);
(gdb)
264 finfo->valid |= APR_FINFO_NAME;
(gdb)
266 if (wanted)
(gdb)
269 return APR_SUCCESS;
(gdb)
Subversion explicitly requests APR_FINFO_TYPE but then the
apr_dir_read code clears that bit and so doesn't call apr_lstat.
APR_UNKFILE appears to be correct for d_type of 0, but is not a very
useful thing for APR to return in response to APR_FINFO_TYPE. It's a
change in APR's behaviour and it breaks Subversion.
--
Philip Martin
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by Philip Martin <ph...@codematters.co.uk>.
"William A. Rowe, Jr." <wr...@apache.org> writes:
> What I would like to know (if you can track it...)
>
> Is it possible to dump the finfo structure within gdb at the point this
> request fails? I'd pay especially close attention to the .valid bits, since
> those are the identifiers that will help us determine if stat() was also
> called later.
This is for dir.c version 1.71 with the patch reverted. The
Subversion code is svn_io_get_dirents in subversion/libsvn_subr/io.c,
it passes APR_FINFO_TYPE | APR_FINFO_NAME to apr_dir_read. The first
two calls to apr_dir_read return "." and ".." and the Subversion code
skips them, the following gdb information is for the third call
(gdb) s
apr_dir_read (finfo=0xbffff660, wanted=33587200, thedir=0x809a878) at dir.c:174
174 apr_status_t ret = 0;
(gdb) n
179 ret = readdir_r(thedir->dirstruct, thedir->entry, &retent);
(gdb)
184 if(!ret && thedir->entry != retent)
(gdb) p ret
$1 = 0
(gdb) p thedir->entry[0]
$2 = {d_ino = 186434, d_off = 13512064, d_reclen = 16, d_type = 0 '\0',
d_name = "..", '\0' <repeats 253 times>}
(gdb) n
194 if (ret == EINVAL) {
(gdb)
214 finfo->fname = NULL;
(gdb)
216 if (ret) {
(gdb)
222 wanted &= ~APR_FINFO_INODE;
(gdb) p/x wanted
$3 = 0x2008000
(gdb) n
225 wanted &= ~APR_FINFO_TYPE;
(gdb)
228 wanted &= ~APR_FINFO_NAME;
(gdb)
230 if (wanted)
(gdb) p wanted
$4 = 0
(gdb) n
244 if (wanted && (ret == APR_SUCCESS || ret == APR_INCOMPLETE)) {
(gdb)
251 finfo->pool = thedir->pool;
(gdb)
252 finfo->valid = 0;
(gdb)
254 finfo->filetype = filetype_from_dirent_type(thedir->entry->DIRENT_TYPE);
(gdb)
255 finfo->valid |= APR_FINFO_TYPE;
(gdb) p finfo->filetype
$5 = APR_UNKFILE
(gdb) n
258 finfo->inode = thedir->entry->DIRENT_INODE;
(gdb)
259 finfo->valid |= APR_FINFO_INODE;
(gdb)
263 finfo->name = apr_pstrdup(thedir->pool, thedir->entry->d_name);
(gdb)
264 finfo->valid |= APR_FINFO_NAME;
(gdb)
266 if (wanted)
(gdb)
269 return APR_SUCCESS;
(gdb)
Subversion explicitly requests APR_FINFO_TYPE but then the
apr_dir_read code clears that bit and so doesn't call apr_lstat.
APR_UNKFILE appears to be correct for d_type of 0, but is not a very
useful thing for APR to return in response to APR_FINFO_TYPE. It's a
change in APR's behaviour and it breaks Subversion.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 10:42 PM 12/17/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>Obviously, the type at least did not make it into the fle info. Looking
>at this code again, the patch may indeed be wrong; but I find it really,
>really hard to follow that code. In fact, I can't understand it at all.
>If you can enlighten me about what's happening there, I may be able to
>come up with a better patch.
What I would like to know (if you can track it...)
Is it possible to dump the finfo structure within gdb at the point this
request fails? I'd pay especially close attention to the .valid bits, since
those are the identifiers that will help us determine if stat() was also
called later.
First; the definition of all the apr_file_info...() fn's is to return *ALL* of the
available information. If more information is available (without extra
effort) than the user requests, that is always OK.
If some 'extra step' must be performed on a given platfrom (e.g. win32 can't
just get an inode/dev without drilling with an open file handle), then we
*must* perform that extra step.
I'm very interested in what is returned in .filetype. The definition of d_type
is to spell out what info is available about the file directory entry. This is
an lstat() style info (that is, the file doesn't reside in a directory, the
link to the file does.)
>I reverted my change, but be aware that apr_dir_read is currently
>broken. It simply does not work on Linux with a redent glibc, it also
>doesn't work in Solaris 7 (at least for me), etc. etc. It must be fixed.
Thanks... If you can spell out how we called apr_dir_read it might help
me a ton. I'm actively interested in helping debug the issue with the
right fix.
A.F.A rbb's complaint; if this code is difficult to read, by all means we
should refactor for clarity.
However, there is no reason *not* to deal with ALL of the information
we can recover from struct dirent, if it proves reliable. I strongly suspect
we are looking for some unrelated datum that we 1) didn't request, or
2) recovered an APR_INCOMPLETE because some bit was requested
that can't be recovered on the platform in question. Or 3) there is some
very obvious, fat fingered mistake of mine in the code.
Bill
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 10:42 PM 12/17/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>Obviously, the type at least did not make it into the fle info. Looking
>at this code again, the patch may indeed be wrong; but I find it really,
>really hard to follow that code. In fact, I can't understand it at all.
>If you can enlighten me about what's happening there, I may be able to
>come up with a better patch.
What I would like to know (if you can track it...)
Is it possible to dump the finfo structure within gdb at the point this
request fails? I'd pay especially close attention to the .valid bits, since
those are the identifiers that will help us determine if stat() was also
called later.
First; the definition of all the apr_file_info...() fn's is to return *ALL* of the
available information. If more information is available (without extra
effort) than the user requests, that is always OK.
If some 'extra step' must be performed on a given platfrom (e.g. win32 can't
just get an inode/dev without drilling with an open file handle), then we
*must* perform that extra step.
I'm very interested in what is returned in .filetype. The definition of d_type
is to spell out what info is available about the file directory entry. This is
an lstat() style info (that is, the file doesn't reside in a directory, the
link to the file does.)
>I reverted my change, but be aware that apr_dir_read is currently
>broken. It simply does not work on Linux with a redent glibc, it also
>doesn't work in Solaris 7 (at least for me), etc. etc. It must be fixed.
Thanks... If you can spell out how we called apr_dir_read it might help
me a ton. I'm actively interested in helping debug the issue with the
right fix.
A.F.A rbb's complaint; if this code is difficult to read, by all means we
should refactor for clarity.
However, there is no reason *not* to deal with ALL of the information
we can recover from struct dirent, if it proves reliable. I strongly suspect
we are looking for some unrelated datum that we 1) didn't request, or
2) recovered an APR_INCOMPLETE because some bit was requested
that can't be recovered on the platform in question. Or 3) there is some
very obvious, fat fingered mistake of mine in the code.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:
>I'm sorry... this patch dir not come through to dev@apr for me today
>(although I watched for it...) but it's simply WRONG.
>
>
>
>At 07:04 PM 12/17/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>
>
>>>--- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 -0000 1.69
>>>+++ apr/file_io/unix/dir.c 17 Dec 2002 00:49:35 -0000
>>>@@ -218,10 +218,10 @@
>>> return ret;
>>> }
>>>
>>>-#ifdef DIRENT_INODE
>>>+#ifndef DIRENT_INODE
>>> wanted &= ~APR_FINFO_INODE;
>>>#endif
>>>
>>>
>
>Old logic; if we have an INODE from dirent, we don't care that we
>want an INODE from stat() because we already have the INODE.
>
>New Logic: if we don't have an INODE, we won't ask for an INODE
>from stat().
>
>I'm sorry, but that's just broken.
>'
>Please revert and (re)post the original description of the problem.
>
>If you pass APR_FINFO_TYPE | APR_FINFO_INDOE | APR_FINFO_NAME
>that is *ALL* you are promised... we do NOT stat for info you don't ask for.
>
>Bill
>
Here's the original report:
>Philip Martin <ph...@codematters.co.uk> writes:
>
>
>
>>> Eeek!
>>>
>>> I've just upgraded to apache/apr/apr-util to HEAD and now I can
>>> reproduce this.
>>>
>>> $ svnadmin create repo
>>> $ svn mkdir file://`pwd`/repo/foo
>>> $ svn co file://`pwd`/repo wc
>>> $ svn up wc
>>> ../svn/subversion/libsvn_wc/adm_crawler.c:315: (apr_err=155000, src_err=0)
>>> svn: Obstructed update
>>> svn: The entry 'bar' is no longer a directory,
>>> which prevents proper updates.
>>> Please remove this entry and try updating again.
>>
>>
>
>Looks like a recent apr change causes apr_dir_read to fail to return
>all the requested information. I don't know if this is complete from
>an apr point of view, but it's sufficient to get Subversion working on
>my glibc 2.2.5 Linux machine.
>
>
>Index: apr/file_io/unix/dir.c
>===================================================================
>RCS file: /home/cvspublic/apr/file_io/unix/dir.c,v
>retrieving revision 1.69
>diff -u -r1.69 dir.c
>--- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 -0000 1.69
>+++ apr/file_io/unix/dir.c 17 Dec 2002 00:49:35 -0000
>@@ -218,10 +218,10 @@
> return ret;
> }
>
>-#ifdef DIRENT_INODE
>+#ifndef DIRENT_INODE
> wanted &= ~APR_FINFO_INODE;
> #endif
>-#ifdef DIRENT_TYPE
>+#ifndef DIRENT_TYPE
> wanted &= ~APR_FINFO_TYPE;
> #endif
>
> -- Philip Martin
>
Obviously, the type at least did not make it into the fle info. Looking
at this code again, the patch may indeed be wrong; but I find it really,
really hard to follow that code. In fact, I can't understand it at all.
If you can enlighten me about what's happening there, I may be able to
come up with a better patch.
I reverted my change, but be aware that apr_dir_read is currently
broken. It simply does not work on Linux with a redent glibc, it also
doesn't work in Solaris 7 (at least for me), etc. etc. It must be fixed.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:
>I'm sorry... this patch dir not come through to dev@apr for me today
>(although I watched for it...) but it's simply WRONG.
>
>
>
>At 07:04 PM 12/17/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>
>
>>>--- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 -0000 1.69
>>>+++ apr/file_io/unix/dir.c 17 Dec 2002 00:49:35 -0000
>>>@@ -218,10 +218,10 @@
>>> return ret;
>>> }
>>>
>>>-#ifdef DIRENT_INODE
>>>+#ifndef DIRENT_INODE
>>> wanted &= ~APR_FINFO_INODE;
>>>#endif
>>>
>>>
>
>Old logic; if we have an INODE from dirent, we don't care that we
>want an INODE from stat() because we already have the INODE.
>
>New Logic: if we don't have an INODE, we won't ask for an INODE
>from stat().
>
>I'm sorry, but that's just broken.
>'
>Please revert and (re)post the original description of the problem.
>
>If you pass APR_FINFO_TYPE | APR_FINFO_INDOE | APR_FINFO_NAME
>that is *ALL* you are promised... we do NOT stat for info you don't ask for.
>
>Bill
>
Here's the original report:
>Philip Martin <ph...@codematters.co.uk> writes:
>
>
>
>>> Eeek!
>>>
>>> I've just upgraded to apache/apr/apr-util to HEAD and now I can
>>> reproduce this.
>>>
>>> $ svnadmin create repo
>>> $ svn mkdir file://`pwd`/repo/foo
>>> $ svn co file://`pwd`/repo wc
>>> $ svn up wc
>>> ../svn/subversion/libsvn_wc/adm_crawler.c:315: (apr_err=155000, src_err=0)
>>> svn: Obstructed update
>>> svn: The entry 'bar' is no longer a directory,
>>> which prevents proper updates.
>>> Please remove this entry and try updating again.
>>
>>
>
>Looks like a recent apr change causes apr_dir_read to fail to return
>all the requested information. I don't know if this is complete from
>an apr point of view, but it's sufficient to get Subversion working on
>my glibc 2.2.5 Linux machine.
>
>
>Index: apr/file_io/unix/dir.c
>===================================================================
>RCS file: /home/cvspublic/apr/file_io/unix/dir.c,v
>retrieving revision 1.69
>diff -u -r1.69 dir.c
>--- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 -0000 1.69
>+++ apr/file_io/unix/dir.c 17 Dec 2002 00:49:35 -0000
>@@ -218,10 +218,10 @@
> return ret;
> }
>
>-#ifdef DIRENT_INODE
>+#ifndef DIRENT_INODE
> wanted &= ~APR_FINFO_INODE;
> #endif
>-#ifdef DIRENT_TYPE
>+#ifndef DIRENT_TYPE
> wanted &= ~APR_FINFO_TYPE;
> #endif
>
> -- Philip Martin
>
Obviously, the type at least did not make it into the fle info. Looking
at this code again, the patch may indeed be wrong; but I find it really,
really hard to follow that code. In fact, I can't understand it at all.
If you can enlighten me about what's happening there, I may be able to
come up with a better patch.
I reverted my change, but be aware that apr_dir_read is currently
broken. It simply does not work on Linux with a redent glibc, it also
doesn't work in Solaris 7 (at least for me), etc. etc. It must be fixed.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by rb...@apache.org.
On Tue, 17 Dec 2002, William A. Rowe, Jr. wrote:
> I'm sorry... this patch dir not come through to dev@apr for me today
> (although I watched for it...) but it's simply WRONG.
>
> At 07:04 PM 12/17/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
> >>--- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 -0000 1.69
> >>+++ apr/file_io/unix/dir.c 17 Dec 2002 00:49:35 -0000
> >>@@ -218,10 +218,10 @@
> >> return ret;
> >> }
> >>
> >>-#ifdef DIRENT_INODE
> >>+#ifndef DIRENT_INODE
> >> wanted &= ~APR_FINFO_INODE;
> >> #endif
>
> Old logic; if we have an INODE from dirent, we don't care that we
> want an INODE from stat() because we already have the INODE.
>
> New Logic: if we don't have an INODE, we won't ask for an INODE
> from stat().
>
> I'm sorry, but that's just broken.
> '
> Please revert and (re)post the original description of the problem.
>
> If you pass APR_FINFO_TYPE | APR_FINFO_INDOE | APR_FINFO_NAME
> that is *ALL* you are promised... we do NOT stat for info you don't ask for.
Am I the only person who believes that our stat API is incredibly complex
and over-engineered? If I am, I will drop it, but if I'm not can we take
the time to fix it?
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by rb...@apache.org.
On Tue, 17 Dec 2002, William A. Rowe, Jr. wrote:
> I'm sorry... this patch dir not come through to dev@apr for me today
> (although I watched for it...) but it's simply WRONG.
>
> At 07:04 PM 12/17/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
> >>--- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 -0000 1.69
> >>+++ apr/file_io/unix/dir.c 17 Dec 2002 00:49:35 -0000
> >>@@ -218,10 +218,10 @@
> >> return ret;
> >> }
> >>
> >>-#ifdef DIRENT_INODE
> >>+#ifndef DIRENT_INODE
> >> wanted &= ~APR_FINFO_INODE;
> >> #endif
>
> Old logic; if we have an INODE from dirent, we don't care that we
> want an INODE from stat() because we already have the INODE.
>
> New Logic: if we don't have an INODE, we won't ask for an INODE
> from stat().
>
> I'm sorry, but that's just broken.
> '
> Please revert and (re)post the original description of the problem.
>
> If you pass APR_FINFO_TYPE | APR_FINFO_INDOE | APR_FINFO_NAME
> that is *ALL* you are promised... we do NOT stat for info you don't ask for.
Am I the only person who believes that our stat API is incredibly complex
and over-engineered? If I am, I will drop it, but if I'm not can we take
the time to fix it?
Ryan
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
I'm sorry... this patch dir not come through to dev@apr for me today
(although I watched for it...) but it's simply WRONG.
At 07:04 PM 12/17/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>>--- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 -0000 1.69
>>+++ apr/file_io/unix/dir.c 17 Dec 2002 00:49:35 -0000
>>@@ -218,10 +218,10 @@
>> return ret;
>> }
>>
>>-#ifdef DIRENT_INODE
>>+#ifndef DIRENT_INODE
>> wanted &= ~APR_FINFO_INODE;
>> #endif
Old logic; if we have an INODE from dirent, we don't care that we
want an INODE from stat() because we already have the INODE.
New Logic: if we don't have an INODE, we won't ask for an INODE
from stat().
I'm sorry, but that's just broken.
'
Please revert and (re)post the original description of the problem.
If you pass APR_FINFO_TYPE | APR_FINFO_INDOE | APR_FINFO_NAME
that is *ALL* you are promised... we do NOT stat for info you don't ask for.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
I'm sorry... this patch dir not come through to dev@apr for me today
(although I watched for it...) but it's simply WRONG.
At 07:04 PM 12/17/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>>--- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 -0000 1.69
>>+++ apr/file_io/unix/dir.c 17 Dec 2002 00:49:35 -0000
>>@@ -218,10 +218,10 @@
>> return ret;
>> }
>>
>>-#ifdef DIRENT_INODE
>>+#ifndef DIRENT_INODE
>> wanted &= ~APR_FINFO_INODE;
>> #endif
Old logic; if we have an INODE from dirent, we don't care that we
want an INODE from stat() because we already have the INODE.
New Logic: if we don't have an INODE, we won't ask for an INODE
from stat().
I'm sorry, but that's just broken.
'
Please revert and (re)post the original description of the problem.
If you pass APR_FINFO_TYPE | APR_FINFO_INDOE | APR_FINFO_NAME
that is *ALL* you are promised... we do NOT stat for info you don't ask for.
Bill
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Philip Martin <ph...@codematters.co.uk> writes:
>
>
>
>>Eeek!
>>
>>I've just upgraded to apache/apr/apr-util to HEAD and now I can
>>reproduce this.
>>
>>$ svnadmin create repo
>>$ svn mkdir file://`pwd`/repo/foo
>>$ svn co file://`pwd`/repo wc
>>$ svn up wc
>>../svn/subversion/libsvn_wc/adm_crawler.c:315: (apr_err=155000, src_err=0)
>>svn: Obstructed update
>>svn: The entry 'bar' is no longer a directory,
>>which prevents proper updates.
>>Please remove this entry and try updating again.
>>
>>
>
>Looks like a recent apr change causes apr_dir_read to fail to return
>all the requested information. I don't know if this is complete from
>an apr point of view, but it's sufficient to get Subversion working on
>my glibc 2.2.5 Linux machine.
>
>
>Index: apr/file_io/unix/dir.c
>===================================================================
>RCS file: /home/cvspublic/apr/file_io/unix/dir.c,v
>retrieving revision 1.69
>diff -u -r1.69 dir.c
>--- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 -0000 1.69
>+++ apr/file_io/unix/dir.c 17 Dec 2002 00:49:35 -0000
>@@ -218,10 +218,10 @@
> return ret;
> }
>
>-#ifdef DIRENT_INODE
>+#ifndef DIRENT_INODE
> wanted &= ~APR_FINFO_INODE;
> #endif
>-#ifdef DIRENT_TYPE
>+#ifndef DIRENT_TYPE
> wanted &= ~APR_FINFO_TYPE;
> #endif
>
>
>
Yup, your patch fixes my problem, too. Committed in version 1.70. Thanks!
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] apr_dir_read doesn't return requested information
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Philip Martin <ph...@codematters.co.uk> writes:
>
>
>
>>Eeek!
>>
>>I've just upgraded to apache/apr/apr-util to HEAD and now I can
>>reproduce this.
>>
>>$ svnadmin create repo
>>$ svn mkdir file://`pwd`/repo/foo
>>$ svn co file://`pwd`/repo wc
>>$ svn up wc
>>../svn/subversion/libsvn_wc/adm_crawler.c:315: (apr_err=155000, src_err=0)
>>svn: Obstructed update
>>svn: The entry 'bar' is no longer a directory,
>>which prevents proper updates.
>>Please remove this entry and try updating again.
>>
>>
>
>Looks like a recent apr change causes apr_dir_read to fail to return
>all the requested information. I don't know if this is complete from
>an apr point of view, but it's sufficient to get Subversion working on
>my glibc 2.2.5 Linux machine.
>
>
>Index: apr/file_io/unix/dir.c
>===================================================================
>RCS file: /home/cvspublic/apr/file_io/unix/dir.c,v
>retrieving revision 1.69
>diff -u -r1.69 dir.c
>--- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 -0000 1.69
>+++ apr/file_io/unix/dir.c 17 Dec 2002 00:49:35 -0000
>@@ -218,10 +218,10 @@
> return ret;
> }
>
>-#ifdef DIRENT_INODE
>+#ifndef DIRENT_INODE
> wanted &= ~APR_FINFO_INODE;
> #endif
>-#ifdef DIRENT_TYPE
>+#ifndef DIRENT_TYPE
> wanted &= ~APR_FINFO_TYPE;
> #endif
>
>
>
Yup, your patch fixes my problem, too. Committed in version 1.70. Thanks!
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
[PATCH] apr_dir_read doesn't return requested information
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> Eeek!
>
> I've just upgraded to apache/apr/apr-util to HEAD and now I can
> reproduce this.
>
> $ svnadmin create repo
> $ svn mkdir file://`pwd`/repo/foo
> $ svn co file://`pwd`/repo wc
> $ svn up wc
> ../svn/subversion/libsvn_wc/adm_crawler.c:315: (apr_err=155000, src_err=0)
> svn: Obstructed update
> svn: The entry 'bar' is no longer a directory,
> which prevents proper updates.
> Please remove this entry and try updating again.
Looks like a recent apr change causes apr_dir_read to fail to return
all the requested information. I don't know if this is complete from
an apr point of view, but it's sufficient to get Subversion working on
my glibc 2.2.5 Linux machine.
Index: apr/file_io/unix/dir.c
===================================================================
RCS file: /home/cvspublic/apr/file_io/unix/dir.c,v
retrieving revision 1.69
diff -u -r1.69 dir.c
--- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 -0000 1.69
+++ apr/file_io/unix/dir.c 17 Dec 2002 00:49:35 -0000
@@ -218,10 +218,10 @@
return ret;
}
-#ifdef DIRENT_INODE
+#ifndef DIRENT_INODE
wanted &= ~APR_FINFO_INODE;
#endif
-#ifdef DIRENT_TYPE
+#ifndef DIRENT_TYPE
wanted &= ~APR_FINFO_TYPE;
#endif
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Is Apache HEAD incompatible with Subversion? [Was: Obstructed update]
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> Sebastian Bergmann <sb...@sebastian-bergmann.de> writes:
>
> > > Which version of APR?
> >
> > Current HEAD.
>
> Eeek!
>
> I've just upgraded to apache/apr/apr-util to HEAD and now I can
> reproduce this.
>
> $ svnadmin create repo
> $ svn mkdir file://`pwd`/repo/foo
> $ svn co file://`pwd`/repo wc
> $ svn up wc
> ../svn/subversion/libsvn_wc/adm_crawler.c:315: (apr_err=155000, src_err=0)
> svn: Obstructed update
> svn: The entry 'bar' is no longer a directory,
> which prevents proper updates.
> Please remove this entry and try updating again.
Reverting the recent changes to apr/file_io/unix/dir.c with
$ cvs up -r1.64 apr/file_io/unix/dir.c
appears to fix the problem.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] apr_dir_read doesn't return requested information
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> Eeek!
>
> I've just upgraded to apache/apr/apr-util to HEAD and now I can
> reproduce this.
>
> $ svnadmin create repo
> $ svn mkdir file://`pwd`/repo/foo
> $ svn co file://`pwd`/repo wc
> $ svn up wc
> ../svn/subversion/libsvn_wc/adm_crawler.c:315: (apr_err=155000, src_err=0)
> svn: Obstructed update
> svn: The entry 'bar' is no longer a directory,
> which prevents proper updates.
> Please remove this entry and try updating again.
Looks like a recent apr change causes apr_dir_read to fail to return
all the requested information. I don't know if this is complete from
an apr point of view, but it's sufficient to get Subversion working on
my glibc 2.2.5 Linux machine.
Index: apr/file_io/unix/dir.c
===================================================================
RCS file: /home/cvspublic/apr/file_io/unix/dir.c,v
retrieving revision 1.69
diff -u -r1.69 dir.c
--- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 -0000 1.69
+++ apr/file_io/unix/dir.c 17 Dec 2002 00:49:35 -0000
@@ -218,10 +218,10 @@
return ret;
}
-#ifdef DIRENT_INODE
+#ifndef DIRENT_INODE
wanted &= ~APR_FINFO_INODE;
#endif
-#ifdef DIRENT_TYPE
+#ifndef DIRENT_TYPE
wanted &= ~APR_FINFO_TYPE;
#endif
--
Philip Martin
Re: Is Apache HEAD incompatible with Subversion? [Was: Obstructed update]
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> $ svnadmin create repo
> $ svn mkdir file://`pwd`/repo/foo
> $ svn co file://`pwd`/repo wc
> $ svn up wc
> ../svn/subversion/libsvn_wc/adm_crawler.c:315: (apr_err=155000, src_err=0)
> svn: Obstructed update
> svn: The entry 'bar' is no longer a directory,
> which prevents proper updates.
> Please remove this entry and try updating again.
> $ svn info wc/bar
Oops, didn't paste the right command (I've run this a few times), but
if I run svn info wc/foo I get essentially the same information: it's
a valid working copy directory.
> Path: wc/bar
> Url: file:///home/pm/sw/subversion/obj/subversion/tests/clients/cmdline/foo/bar
> Revision: 1
> Node Kind: directory
> Schedule: normal
> Last Changed Author: pm
> Last Changed Rev: 1
> Last Changed Date: 2002-12-16 23:27:45 +0000 (Mon, 16 Dec 2002)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Is Apache HEAD incompatible with Subversion? [Was: Obstructed update]
Posted by Philip Martin <ph...@codematters.co.uk>.
Sebastian Bergmann <sb...@sebastian-bergmann.de> writes:
> > Which version of APR?
>
> Current HEAD.
Eeek!
I've just upgraded to apache/apr/apr-util to HEAD and now I can
reproduce this.
$ svnadmin create repo
$ svn mkdir file://`pwd`/repo/foo
$ svn co file://`pwd`/repo wc
$ svn up wc
../svn/subversion/libsvn_wc/adm_crawler.c:315: (apr_err=155000, src_err=0)
svn: Obstructed update
svn: The entry 'bar' is no longer a directory,
which prevents proper updates.
Please remove this entry and try updating again.
$ svn info wc/bar
Path: wc/bar
Url: file:///home/pm/sw/subversion/obj/subversion/tests/clients/cmdline/foo/bar
Revision: 1
Node Kind: directory
Schedule: normal
Last Changed Author: pm
Last Changed Rev: 1
Last Changed Date: 2002-12-16 23:27:45 +0000 (Mon, 16 Dec 2002)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obstructed update
Posted by Bob Gustafson <bo...@rcnChicago.com>.
Note, this may not have anything to do with your problem, however,
I am running DB 4.1.24, RedHat 7.3, httpd 2.0.43 and latest svn.
My make check works fine. See config below
[root@hoho0 svn_new]# more conf.rdg.sh
./configure \
--with-apr=/usr/local/apache2 \
--with-apr-util=/usr/local/apache2 \
--with-berkeley-db=/usr/local/BerkeleyDB.4.1 \
--with-ssl --with-zlib \
2>&1 | tee config.out
# ./configure --enable-maintainer-mode \
[root@hoho0 svn_new]#
I did notice that there was a tweek in DB between 4.0 and 4.1 - an extra
argument in a couple of the commands. When I built apr-util, I needed a
patch before it would work. I did submit patch, and it may be in apr-util
now.
You might try to rebuild your apr-util and see if there are complaints
about DB4.1.24
BobG
>Philip Martin wrote:
>> It looks like you are using x86 Suse-Linux, correct?
>
> Yes, it's a SuSE 8.0, but quite modified: Kernel 2.4.20, GCC 3.2.1 and
> recent binutils, autoconf 2.56, automake 1.5, libtool 1.4.3, make 3.80.
>
> Which reminds me of something: I installed Berkeley DB 4.1.24, but the
> INSTALL speaks of version 4.0.14. Could this have something to do with
> it?
>
>> Which version of Subversion are you using?
>
> Can't remember what revision I used to create the backtrace, but I just
> made a new checkout (revision 4136).
>
>> Which version of APR?
>
> Current HEAD.
>
>> Did you build them yourself?
>
> Yes.
>
>> Did you run the Subversion regression tests? Did they pass?
>
>sb@wopr-mobile:/usr/src/subversion> make check
>Running all tests in hashdump-test...success
>Running all tests in path-test...success
>Running all tests in random-test...success
>Running all tests in stream-test...success
>Running all tests in stringtest...success
>Running all tests in time-test...success
>Running all tests in translate-test...success
>Running all tests in target-test.py...success
>Running all tests in run-fs-tests.py...FAILURE
>Running all tests in run-repos-tests.py...success
>Running all tests in getopt_tests.py...success
>Running all tests in basic_tests.py...FAILURE
>Running all tests in commit_tests.py...FAILURE
>Running all tests in update_tests.py...FAILURE
>Running all tests in switch_tests.py...FAILURE
>Running all tests in prop_tests.py...FAILURE
>Running all tests in schedule_tests.py...FAILURE
>Running all tests in log_tests.py...FAILURE
>Running all tests in copy_tests.py...FAILURE
>Running all tests in diff_tests.py...FAILURE
>Running all tests in externals_tests.py...FAILURE
>Running all tests in merge_tests.py...FAILURE
>Running all tests in stat_tests.py...FAILURE
>Running all tests in trans_tests.py...FAILURE
>Running all tests in svnadmin_tests.py...FAILURE
>Running all tests in svnlook_tests.py...FAILURE
>At least one test FAILED, checking /usr/src/subversion/tests.log
>FAIL: basic_tests.py 1: basic checkout of a wc
>FAIL: basic_tests.py 2: basic status command
>FAIL: basic_tests.py 3: basic commit command
>FAIL: basic_tests.py 4: basic update command
>FAIL: basic_tests.py 5: basic corruption detection
>FAIL: basic_tests.py 6: receiving text merges as part of an update
>FAIL: basic_tests.py 7: basic conflict creation and resolution
>FAIL: basic_tests.py 8: basic cleanup command
>FAIL: basic_tests.py 9: basic revert command
>FAIL: basic_tests.py 10: basic switch command
>FAIL: basic_tests.py 11: basic delete command
>FAIL: basic_tests.py 12: checkout a path no longer in HEAD
>FAIL: basic_tests.py 13: attempt to change node kind
>FAIL: basic_tests.py 14: basic import of single new file
>FAIL: basic_tests.py 15: basic cat of files
>FAIL: basic_tests.py 16: basic import of executable files
>FAIL: commit_tests.py 1: commit one file.
>FAIL: commit_tests.py 2: commit one newly added file.
>FAIL: commit_tests.py 3: commit one newly added binary file.
>FAIL: commit_tests.py 4: commit multiple targets
>FAIL: commit_tests.py 5: commit multiple targets, 2nd variation
>FAIL: commit_tests.py 6: commit wc_dir/A/D -- includes D. (anchor=A,
>tgt=D)
>FAIL: commit_tests.py 7: commit wc_dir -- (anchor=wc_dir, tgt={})
>FAIL: commit_tests.py 8: committing unversioned object produces error
>FAIL: commit_tests.py 9: replace two nested dirs, verify empty contents
>FAIL: commit_tests.py 10: hudson prob 1.0: delete file, commit, update
>FAIL: commit_tests.py 11: hudson prob 1.1: delete dir, commit, update
>FAIL: commit_tests.py 12: hudson prob 1.2: delete, commit, re-add,
>commit
>FAIL: commit_tests.py 13: hudson prob 2.0: prop commit on old dir fails.
>FAIL: commit_tests.py 15: commit mixed-rev wc (no erronous merge error)
>FAIL: commit_tests.py 16: commit files and dirs with URI-unsafe
>characters
>FAIL: commit_tests.py 17: commit files that have been deleted, but also
>edited
>FAIL: commit_tests.py 18: commit a file inside dir scheduled for addition
>FAIL: commit_tests.py 19: commit deleted (and missing) file
>FAIL: commit_tests.py 20: issue 644 attempt to add a file twice
>FAIL: commit_tests.py 21: commit from a dir with a longer name than the
>wc
>FAIL: commit_tests.py 22: try to commit when directory is locked
>FAIL: commit_tests.py 23: commit the current directory
>FAIL: commit_tests.py 24: attempted commit from multiple wc fails
>FAIL: update_tests.py 1: update a locally-modified binary file
>FAIL: update_tests.py 2: update to an old revision of a binary files
>FAIL: update_tests.py 3: ensure update is not munging additions or
>replacements
>FAIL: update_tests.py 4: update to revision 0
>FAIL: update_tests.py 5: make sure overlapping identical changes do not
>conflict
>FAIL: update_tests.py 6: delete files and update to resolve text
>conflicts
>FAIL: update_tests.py 7: update that deletes modifed files
>FAIL: update_tests.py 8: update after add/rm of deleted state
>FAIL: update_tests.py 9: update missing items (by name) in working copy
>FAIL: update_tests.py 10: update that replaces a directory
>FAIL: update_tests.py 11: update with explict file target
>FAIL: switch_tests.py 1: test some basic switching operations
>FAIL: switch_tests.py 2: commits after some basic switching operations
>FAIL: switch_tests.py 3: update wc that contains switched things
>FAIL: switch_tests.py 4: reverse update wc that contains switched things
>FAIL: switch_tests.py 5: update switched wc things to HEAD
>FAIL: switch_tests.py 6: reverse update switched wc things to an older
>rev
>FAIL: prop_tests.py 1: write/read props in wc only (ps, pl, pdel)
>FAIL: prop_tests.py 2: commit properties
>FAIL: prop_tests.py 3: receive properties via update
>FAIL: prop_tests.py 4: receive property changes as part of a downdate
>FAIL: prop_tests.py 5: commit the removal of props
>FAIL: prop_tests.py 6: update with conflicting props
>FAIL: prop_tests.py 7: props work when committing a replacement
>FAIL: prop_tests.py 8: props work when reverting a replacement
>FAIL: prop_tests.py 9: try to set inappropriate props
>FAIL: prop_tests.py 10: copying a file should use the original
>svn:executable and svn:mime-type
>FAIL: schedule_tests.py 1: schedule: add some files
>FAIL: schedule_tests.py 2: schedule: add some directories
>FAIL: schedule_tests.py 3: schedule: add some nested files and
>directories
>FAIL: schedule_tests.py 4: schedule: add some executable files
>FAIL: schedule_tests.py 5: schedule: delete some files
>FAIL: schedule_tests.py 6: schedule: delete some directories
>FAIL: schedule_tests.py 7: revert: add some files
>FAIL: schedule_tests.py 8: revert: add some directories
>FAIL: schedule_tests.py 9: revert: add some nested files and directories
>FAIL: schedule_tests.py 10: revert: add some executable files
>FAIL: schedule_tests.py 11: revert: delete some files
>FAIL: schedule_tests.py 12: revert: delete some directories
>FAIL: log_tests.py 1: 'svn log', no args, top of wc.
>FAIL: log_tests.py 2: 'svn commit -F foo' when foo is a versioned file
>FAIL: copy_tests.py 1: basic copy and move commands -- on files only
>FAIL: copy_tests.py 2: test fix for 'svn mv unversioned_file some_dst'
>FAIL: copy_tests.py 3: receive a copied directory during update
>FAIL: copy_tests.py 4: resurrect a deleted directory
>FAIL: copy_tests.py 5: svn cp URL URL cannot overwrite destination
>FAIL: copy_tests.py 6: svn cp PATH PATH cannot overwrite destination
>FAIL: copy_tests.py 7: copy a directory hierarchy and modify before
>commit
>FAIL: copy_tests.py 8: copy files with properties
>FAIL: copy_tests.py 9: copy a tree and delete part of it before commit
>FAIL: copy_tests.py 10: move and revert a directory
>FAIL: copy_tests.py 11: executable bit should be preserved when copying
>FAIL: copy_tests.py 12: working-copy to repository copy
>FAIL: diff_tests.py 1: update a file
>FAIL: diff_tests.py 2: add a file
>FAIL: diff_tests.py 3: add a file in an added directory
>FAIL: diff_tests.py 4: replace a file with a file
>FAIL: diff_tests.py 5: multiple revisions diff'd forwards and backwards
>FAIL: diff_tests.py 6: non-recursive behaviour
>FAIL: diff_tests.py 7: diff only part of the repository
>FAIL: diff_tests.py 8: non version controlled files
>FAIL: diff_tests.py 9: pure repository diff update a file
>FAIL: diff_tests.py 10: diff when property was changed but text was not
>FAIL: externals_tests.py 1: check out a directory with some external
>modules attached
>FAIL: externals_tests.py 2: update to receive a new external module.
>FAIL: externals_tests.py 3: update to lose an external module.
>FAIL: externals_tests.py 4: update to receive a change to an unmodifed
>external module.
>FAIL: externals_tests.py 5: update to receive a change to a modified
>external module.
>FAIL: externals_tests.py 6: update to receive a change under an external
>module.
>FAIL: externals_tests.py 7: modify to specify, and update to receive, a
>new external module
>FAIL: merge_tests.py 1: performing a merge, with mixed results
>FAIL: merge_tests.py 2: merge and add new files/dirs with history
>FAIL: merge_tests.py 3: merge and that deletes items
>FAIL: merge_tests.py 4: some simple property merges
>FAIL: stat_tests.py 1: run status on an unversioned file in the current
>directory
>FAIL: stat_tests.py 2: run 'status -u' when nested additions are pending
>FAIL: stat_tests.py 3: status -vN and test if all items in the current
>directory show up
>FAIL: stat_tests.py 4: status with a versioned file missing
>FAIL: stat_tests.py 5: status with versioned items whose working type has
>changed
>FAIL: stat_tests.py 6: status -u with new files pending in the repository
>(tests rev 3686)
>FAIL: stat_tests.py 7: status blank for unignored file
>FAIL: trans_tests.py 1: commit new files with keywords active from birth
>FAIL: trans_tests.py 5: update locally modified file with eol-style
>'native'
>FAIL: svnadmin_tests.py 1: test 'svnadmin create' subcommand
>FAIL: svnadmin_tests.py 2: test 'svnadmin createtxn' subcommand
>FAIL: svnadmin_tests.py 3: test 'svnadmin rmtxns' subcommand
>FAIL: svnadmin_tests.py 4: test 'svnadmin dump' on a copied directory
>FAIL: svnadmin_tests.py 5: test 'svnadmin dump' on modified child of
>copied directory
>FAIL: svnlook_tests.py 1: test 'svnlook youngest' subcommand
>make: *** [check] Error 1
>
>--
> Sebastian Bergmann
> http://sebastian-bergmann.de/ http://phpOpenTracker.de/
>
> Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obstructed update
Posted by Sebastian Bergmann <sb...@sebastian-bergmann.de>.
Philip Martin wrote:
> It looks like you are using x86 Suse-Linux, correct?
Yes, it's a SuSE 8.0, but quite modified: Kernel 2.4.20, GCC 3.2.1 and
recent binutils, autoconf 2.56, automake 1.5, libtool 1.4.3, make 3.80.
Which reminds me of something: I installed Berkeley DB 4.1.24, but the
INSTALL speaks of version 4.0.14. Could this have something to do with
it?
> Which version of Subversion are you using?
Can't remember what revision I used to create the backtrace, but I just
made a new checkout (revision 4136).
> Which version of APR?
Current HEAD.
> Did you build them yourself?
Yes.
> Did you run the Subversion regression tests? Did they pass?
sb@wopr-mobile:/usr/src/subversion> make check
Running all tests in hashdump-test...success
Running all tests in path-test...success
Running all tests in random-test...success
Running all tests in stream-test...success
Running all tests in stringtest...success
Running all tests in time-test...success
Running all tests in translate-test...success
Running all tests in target-test.py...success
Running all tests in run-fs-tests.py...FAILURE
Running all tests in run-repos-tests.py...success
Running all tests in getopt_tests.py...success
Running all tests in basic_tests.py...FAILURE
Running all tests in commit_tests.py...FAILURE
Running all tests in update_tests.py...FAILURE
Running all tests in switch_tests.py...FAILURE
Running all tests in prop_tests.py...FAILURE
Running all tests in schedule_tests.py...FAILURE
Running all tests in log_tests.py...FAILURE
Running all tests in copy_tests.py...FAILURE
Running all tests in diff_tests.py...FAILURE
Running all tests in externals_tests.py...FAILURE
Running all tests in merge_tests.py...FAILURE
Running all tests in stat_tests.py...FAILURE
Running all tests in trans_tests.py...FAILURE
Running all tests in svnadmin_tests.py...FAILURE
Running all tests in svnlook_tests.py...FAILURE
At least one test FAILED, checking /usr/src/subversion/tests.log
FAIL: basic_tests.py 1: basic checkout of a wc
FAIL: basic_tests.py 2: basic status command
FAIL: basic_tests.py 3: basic commit command
FAIL: basic_tests.py 4: basic update command
FAIL: basic_tests.py 5: basic corruption detection
FAIL: basic_tests.py 6: receiving text merges as part of an update
FAIL: basic_tests.py 7: basic conflict creation and resolution
FAIL: basic_tests.py 8: basic cleanup command
FAIL: basic_tests.py 9: basic revert command
FAIL: basic_tests.py 10: basic switch command
FAIL: basic_tests.py 11: basic delete command
FAIL: basic_tests.py 12: checkout a path no longer in HEAD
FAIL: basic_tests.py 13: attempt to change node kind
FAIL: basic_tests.py 14: basic import of single new file
FAIL: basic_tests.py 15: basic cat of files
FAIL: basic_tests.py 16: basic import of executable files
FAIL: commit_tests.py 1: commit one file.
FAIL: commit_tests.py 2: commit one newly added file.
FAIL: commit_tests.py 3: commit one newly added binary file.
FAIL: commit_tests.py 4: commit multiple targets
FAIL: commit_tests.py 5: commit multiple targets, 2nd variation
FAIL: commit_tests.py 6: commit wc_dir/A/D -- includes D. (anchor=A,
tgt=D)
FAIL: commit_tests.py 7: commit wc_dir -- (anchor=wc_dir, tgt={})
FAIL: commit_tests.py 8: committing unversioned object produces error
FAIL: commit_tests.py 9: replace two nested dirs, verify empty contents
FAIL: commit_tests.py 10: hudson prob 1.0: delete file, commit, update
FAIL: commit_tests.py 11: hudson prob 1.1: delete dir, commit, update
FAIL: commit_tests.py 12: hudson prob 1.2: delete, commit, re-add,
commit
FAIL: commit_tests.py 13: hudson prob 2.0: prop commit on old dir fails.
FAIL: commit_tests.py 15: commit mixed-rev wc (no erronous merge error)
FAIL: commit_tests.py 16: commit files and dirs with URI-unsafe
characters
FAIL: commit_tests.py 17: commit files that have been deleted, but also
edited
FAIL: commit_tests.py 18: commit a file inside dir scheduled for addition
FAIL: commit_tests.py 19: commit deleted (and missing) file
FAIL: commit_tests.py 20: issue 644 attempt to add a file twice
FAIL: commit_tests.py 21: commit from a dir with a longer name than the
wc
FAIL: commit_tests.py 22: try to commit when directory is locked
FAIL: commit_tests.py 23: commit the current directory
FAIL: commit_tests.py 24: attempted commit from multiple wc fails
FAIL: update_tests.py 1: update a locally-modified binary file
FAIL: update_tests.py 2: update to an old revision of a binary files
FAIL: update_tests.py 3: ensure update is not munging additions or
replacements
FAIL: update_tests.py 4: update to revision 0
FAIL: update_tests.py 5: make sure overlapping identical changes do not
conflict
FAIL: update_tests.py 6: delete files and update to resolve text
conflicts
FAIL: update_tests.py 7: update that deletes modifed files
FAIL: update_tests.py 8: update after add/rm of deleted state
FAIL: update_tests.py 9: update missing items (by name) in working copy
FAIL: update_tests.py 10: update that replaces a directory
FAIL: update_tests.py 11: update with explict file target
FAIL: switch_tests.py 1: test some basic switching operations
FAIL: switch_tests.py 2: commits after some basic switching operations
FAIL: switch_tests.py 3: update wc that contains switched things
FAIL: switch_tests.py 4: reverse update wc that contains switched things
FAIL: switch_tests.py 5: update switched wc things to HEAD
FAIL: switch_tests.py 6: reverse update switched wc things to an older
rev
FAIL: prop_tests.py 1: write/read props in wc only (ps, pl, pdel)
FAIL: prop_tests.py 2: commit properties
FAIL: prop_tests.py 3: receive properties via update
FAIL: prop_tests.py 4: receive property changes as part of a downdate
FAIL: prop_tests.py 5: commit the removal of props
FAIL: prop_tests.py 6: update with conflicting props
FAIL: prop_tests.py 7: props work when committing a replacement
FAIL: prop_tests.py 8: props work when reverting a replacement
FAIL: prop_tests.py 9: try to set inappropriate props
FAIL: prop_tests.py 10: copying a file should use the original
svn:executable and svn:mime-type
FAIL: schedule_tests.py 1: schedule: add some files
FAIL: schedule_tests.py 2: schedule: add some directories
FAIL: schedule_tests.py 3: schedule: add some nested files and
directories
FAIL: schedule_tests.py 4: schedule: add some executable files
FAIL: schedule_tests.py 5: schedule: delete some files
FAIL: schedule_tests.py 6: schedule: delete some directories
FAIL: schedule_tests.py 7: revert: add some files
FAIL: schedule_tests.py 8: revert: add some directories
FAIL: schedule_tests.py 9: revert: add some nested files and directories
FAIL: schedule_tests.py 10: revert: add some executable files
FAIL: schedule_tests.py 11: revert: delete some files
FAIL: schedule_tests.py 12: revert: delete some directories
FAIL: log_tests.py 1: 'svn log', no args, top of wc.
FAIL: log_tests.py 2: 'svn commit -F foo' when foo is a versioned file
FAIL: copy_tests.py 1: basic copy and move commands -- on files only
FAIL: copy_tests.py 2: test fix for 'svn mv unversioned_file some_dst'
FAIL: copy_tests.py 3: receive a copied directory during update
FAIL: copy_tests.py 4: resurrect a deleted directory
FAIL: copy_tests.py 5: svn cp URL URL cannot overwrite destination
FAIL: copy_tests.py 6: svn cp PATH PATH cannot overwrite destination
FAIL: copy_tests.py 7: copy a directory hierarchy and modify before
commit
FAIL: copy_tests.py 8: copy files with properties
FAIL: copy_tests.py 9: copy a tree and delete part of it before commit
FAIL: copy_tests.py 10: move and revert a directory
FAIL: copy_tests.py 11: executable bit should be preserved when copying
FAIL: copy_tests.py 12: working-copy to repository copy
FAIL: diff_tests.py 1: update a file
FAIL: diff_tests.py 2: add a file
FAIL: diff_tests.py 3: add a file in an added directory
FAIL: diff_tests.py 4: replace a file with a file
FAIL: diff_tests.py 5: multiple revisions diff'd forwards and backwards
FAIL: diff_tests.py 6: non-recursive behaviour
FAIL: diff_tests.py 7: diff only part of the repository
FAIL: diff_tests.py 8: non version controlled files
FAIL: diff_tests.py 9: pure repository diff update a file
FAIL: diff_tests.py 10: diff when property was changed but text was not
FAIL: externals_tests.py 1: check out a directory with some external
modules attached
FAIL: externals_tests.py 2: update to receive a new external module.
FAIL: externals_tests.py 3: update to lose an external module.
FAIL: externals_tests.py 4: update to receive a change to an unmodifed
external module.
FAIL: externals_tests.py 5: update to receive a change to a modified
external module.
FAIL: externals_tests.py 6: update to receive a change under an external
module.
FAIL: externals_tests.py 7: modify to specify, and update to receive, a
new external module
FAIL: merge_tests.py 1: performing a merge, with mixed results
FAIL: merge_tests.py 2: merge and add new files/dirs with history
FAIL: merge_tests.py 3: merge and that deletes items
FAIL: merge_tests.py 4: some simple property merges
FAIL: stat_tests.py 1: run status on an unversioned file in the current
directory
FAIL: stat_tests.py 2: run 'status -u' when nested additions are pending
FAIL: stat_tests.py 3: status -vN and test if all items in the current
directory show up
FAIL: stat_tests.py 4: status with a versioned file missing
FAIL: stat_tests.py 5: status with versioned items whose working type has
changed
FAIL: stat_tests.py 6: status -u with new files pending in the repository
(tests rev 3686)
FAIL: stat_tests.py 7: status blank for unignored file
FAIL: trans_tests.py 1: commit new files with keywords active from birth
FAIL: trans_tests.py 5: update locally modified file with eol-style
'native'
FAIL: svnadmin_tests.py 1: test 'svnadmin create' subcommand
FAIL: svnadmin_tests.py 2: test 'svnadmin createtxn' subcommand
FAIL: svnadmin_tests.py 3: test 'svnadmin rmtxns' subcommand
FAIL: svnadmin_tests.py 4: test 'svnadmin dump' on a copied directory
FAIL: svnadmin_tests.py 5: test 'svnadmin dump' on modified child of
copied directory
FAIL: svnlook_tests.py 1: test 'svnlook youngest' subcommand
make: *** [check] Error 1
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obstructed update
Posted by Philip Martin <ph...@codematters.co.uk>.
Sebastian Bergmann <li...@sebastian-bergmann.de> writes:
> > That should not happen either. Can you print a stack trace:
> >
> > $ gdb /path/to/svn
> > (gdb) r cleanup
> > (gdb) bt
>
> sb@wopr-mobile:/usr/src/subversion> gdb svn
> GNU gdb 5.1.1
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details.
> This GDB was configured as "i386-suse-linux"...
> (gdb) r cleanup
> Starting program: /usr/local/bin/svn cleanup
> [New Thread 1024 (LWP 721)]
> svn: subversion/libsvn_subr/path.c:149: svn_path_join: Assertion
> `is_canonical (component, clen)' failed.
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 1024 (LWP 721)]
> 0x4035dab1 in kill () from /lib/libc.so.6
> (gdb) bt
> #0 0x4035dab1 in kill () from /lib/libc.so.6
> #1 0x402fe982 in pthread_kill () from /lib/libpthread.so.0
> #2 0x402fee6d in raise () from /lib/libpthread.so.0
> #3 0x4035eedb in abort () from /lib/libc.so.6
> #4 0x40357c1b in Letext () from /lib/libc.so.6
> #5 0x400b7808 in svn_path_join (base=0x8076338 "ac-helpers/.svn/tmp",
> component=0x80786a8 ".", pool=0x4044f9c8)
> at subversion/libsvn_subr/path.c:153
> #6 0x400b4acc in svn_io_remove_dir (path=0x8076338 "ac-helpers/.svn/tmp",
> pool=0x8069b48) at subversion/libsvn_subr/io.c:1217
The svn_io_remove_dir code does
if ((this_entry.filetype == APR_DIR)
&& ((this_entry.name[0] == '.')
&& ((this_entry.name[1] == '\0')
|| ((this_entry.name[1] == '.')
&& (this_entry.name[2] == '\0')))))
{
continue;
}
else /* something other than "." or "..", so proceed */
{
//stuff involving svn_path_join
so this looks like the same problem that you have with update, namely
that the file/directory discrimination isn't working. I've never seen
this problem reported before.
It looks like you are using x86 Suse-Linux, correct? Which version of
Subversion are you using? Which version of APR? Did you build them
yourself? Did you run the Subversion regression tests? Did they
pass?
> #7 0x400359ff in svn_wc__adm_cleanup_tmp_area (adm_access=0x8076338,
> pool=0x8078340) at subversion/libsvn_wc/adm_files.c:1248
> #8 0x40041afc in svn_wc_cleanup (path=0x807e340 "ac-helpers",
> optional_adm_access=0x8069e28, pool=0x8069b48)
> at subversion/libsvn_wc/log.c:1396
> #9 0x40041b9d in svn_wc_cleanup (path=0x805fc40 "",
> optional_adm_access=0x0,
> pool=0x8069b48) at subversion/libsvn_wc/log.c:1375
> #10 0x4001bd30 in svn_client_cleanup (dir=0x8076338 "ac-helpers/.svn/tmp",
> pool=0x8078340) at subversion/libsvn_client/cleanup.c:49
> #11 0x0804b152 in svn_cl__cleanup (os=0x0, baton=0x4030a65c,
> pool=0x400c5f74)
> at subversion/clients/cmdline/cleanup-cmd.c:66
> #12 0x0804dd37 in main (argc=1074552692, argv=0x0)
> at subversion/clients/cmdline/main.c:875
> #13 0x4034c9ed in __libc_start_main () from /lib/libc.so.6
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obstructed update
Posted by Sebastian Bergmann <li...@sebastian-bergmann.de>.
Philip Martin wrote:
> The error message was "no longer a directory"
But it's still a directory. The very same that was checked out. I did
not even configure or build the source after checking it out.
> It's not supposed to leave a lock unless there are log files present,
> and would expect the "no longer a directory" error to get generated
> before any log files get created.
>
> Is there a file .svn/log? If so, what does it contain?
> Is there a file ac-helpers/.svn/log? If so, what does it contain?
Neither of those exist.
>> "svn cleanup" yields
>>
>> sb@wopr-mobile:/usr/src/subversion> svn cleanup
>> svn: subversion/libsvn_subr/path.c:149: svn_path_join:
>> Assertion `is_canonical (component, clen)' failed.
>> Aborted
>
> That should not happen either. Can you print a stack trace:
>
> $ gdb /path/to/svn
> (gdb) r cleanup
> (gdb) bt
sb@wopr-mobile:/usr/src/subversion> gdb svn
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-suse-linux"...
(gdb) r cleanup
Starting program: /usr/local/bin/svn cleanup
[New Thread 1024 (LWP 721)]
svn: subversion/libsvn_subr/path.c:149: svn_path_join: Assertion
`is_canonical (component, clen)' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 1024 (LWP 721)]
0x4035dab1 in kill () from /lib/libc.so.6
(gdb) bt
#0 0x4035dab1 in kill () from /lib/libc.so.6
#1 0x402fe982 in pthread_kill () from /lib/libpthread.so.0
#2 0x402fee6d in raise () from /lib/libpthread.so.0
#3 0x4035eedb in abort () from /lib/libc.so.6
#4 0x40357c1b in Letext () from /lib/libc.so.6
#5 0x400b7808 in svn_path_join (base=0x8076338 "ac-helpers/.svn/tmp",
component=0x80786a8 ".", pool=0x4044f9c8)
at subversion/libsvn_subr/path.c:153
#6 0x400b4acc in svn_io_remove_dir (path=0x8076338 "ac-helpers/.svn/tmp",
pool=0x8069b48) at subversion/libsvn_subr/io.c:1217
#7 0x400359ff in svn_wc__adm_cleanup_tmp_area (adm_access=0x8076338,
pool=0x8078340) at subversion/libsvn_wc/adm_files.c:1248
#8 0x40041afc in svn_wc_cleanup (path=0x807e340 "ac-helpers",
optional_adm_access=0x8069e28, pool=0x8069b48)
at subversion/libsvn_wc/log.c:1396
#9 0x40041b9d in svn_wc_cleanup (path=0x805fc40 "",
optional_adm_access=0x0,
pool=0x8069b48) at subversion/libsvn_wc/log.c:1375
#10 0x4001bd30 in svn_client_cleanup (dir=0x8076338 "ac-helpers/.svn/tmp",
pool=0x8078340) at subversion/libsvn_client/cleanup.c:49
#11 0x0804b152 in svn_cl__cleanup (os=0x0, baton=0x4030a65c,
pool=0x400c5f74)
at subversion/clients/cmdline/cleanup-cmd.c:66
#12 0x0804dd37 in main (argc=1074552692, argv=0x0)
at subversion/clients/cmdline/main.c:875
#13 0x4034c9ed in __libc_start_main () from /lib/libc.so.6
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obstructed update
Posted by Philip Martin <ph...@codematters.co.uk>.
Sebastian Bergmann <sb...@sebastian-bergmann.de> writes:
> > I assume ac-helpers was a file, what did it contain?
>
> How could it be a file? It's a directory in the subversion repository
> that was created during checkout:
>
> sb@wopr-mobile:/usr/src/subversion> ll ac-helpers/
> total 108
> -rw-r--r-- 1 sb users 2870 Dec 15 12:38 apr.m4
> -rw-r--r-- 1 sb users 3410 Dec 15 12:38 aprutil.m4
> ...
The error message was "no longer a directory"
sb@wopr-mobile:/usr/src/subversion> svn up
svn: Obstructed update
svn: The entry 'ac-helpers' is no longer a directory,
which prevents proper updates.
Please remove this entry and try updating again.
and I can only generate that error if ac-helpers is a file.
> > What does 'svn status' show?
>
> After the checkout it showed nothing. After the "svn up" with the
> "Obstructed update" message it shows:
>
> sb@wopr-mobile:/usr/src/subversion> svn status
> L .
> L ac-helpers
>
> I guess that the lock was created because of the obstructed update.
It's not supposed to leave a lock unless there are log files present,
and would expect the "no longer a directory" error to get generated
before any log files get created.
Is there a file .svn/log? If so, what does it contain?
Is there a file ac-helpers/.svn/log? If so, what does it contain?
Which version of Subversion are you using? Did you build it yourself?
Do the regression tests pass?
> "svn cleanup" yields
>
> sb@wopr-mobile:/usr/src/subversion> svn cleanup
> svn: subversion/libsvn_subr/path.c:149: svn_path_join:
> Assertion `is_canonical (component, clen)' failed.
> Aborted
That should not happen either. Can you print a stack trace:
$ gdb /path/to/svn
(gdb) r cleanup
(gdb) bt
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obstructed update
Posted by Sebastian Bergmann <sb...@sebastian-bergmann.de>.
Philip Martin wrote:
>> I made a fresh checkout of subversion
>>
>> svn co http://svn.collab.net/repos/svn/trunk subversion
>
> This should create a working copy directory called subversion in the
> current directory. Did you cd into that directory?
Yes.
> Did you run any other commands? Any failed/interrupted checkouts?
No.
> I assume ac-helpers was a file, what did it contain?
How could it be a file? It's a directory in the subversion repository
that was created during checkout:
sb@wopr-mobile:/usr/src/subversion> ll ac-helpers/
total 108
-rw-r--r-- 1 sb users 2870 Dec 15 12:38 apr.m4
-rw-r--r-- 1 sb users 3410 Dec 15 12:38 aprutil.m4
...
> What does 'svn status' show?
After the checkout it showed nothing. After the "svn up" with the
"Obstructed update" message it shows:
sb@wopr-mobile:/usr/src/subversion> svn status
L .
L ac-helpers
I guess that the lock was created because of the obstructed update.
"svn cleanup" yields
sb@wopr-mobile:/usr/src/subversion> svn cleanup
svn: subversion/libsvn_subr/path.c:149: svn_path_join:
Assertion `is_canonical (component, clen)' failed.
Aborted
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obstructed update
Posted by Philip Martin <ph...@codematters.co.uk>.
Sebastian Bergmann <sb...@sebastian-bergmann.de> writes:
> I made a fresh checkout of subversion
>
> svn co http://svn.collab.net/repos/svn/trunk subversion
This should create a working copy directory called subversion in the
current directory. Did you cd into that directory?
> but "svn up" fails with
>
> sb@wopr-mobile:/usr/src/subversion> svn up
> svn: Obstructed update
> svn: The entry 'ac-helpers' is no longer a directory,
> which prevents proper updates.
> Please remove this entry and try updating again.
>
> Removing 'ac-helpers' doesn't solve this, as subversion will then
> complaing about the next directory, and so forth.
Did you run any other commands? Any failed/interrupted checkouts? I
assume ac-helpers was a file, what did it contain? If you don't know
what ac-helpers contained what about one of the other files that
causes the "Obstructed update" error.
What does 'svn status' show?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org