Re: svn status returns incorrect results on Windows 7

2012-01-29 Thread Konstantin Kolinko 
2012/1/27 Justin Johnson :
> Hi,
>
> I am running Subversion 1.7.2 64 bit installer from CollabNet on
> Windows 7.  The problem I'm experiencing can be seen in the output
> below.  In summary, svn status is returning incorrect results,
> sometimes not showing that something has been modified and sometimes
> not recognizing that I'm in a working copy.  This happens for me no
> matter how many times I recreate the working copy, and it happens if I
> store the working copy in C:\Users... as below or in C:\work.  I do
> not have the same problem when trying to reproduce the problem with
> svn 1.7.2 on Solaris.
>
> PS C:\Users\myuser\wc> svn st
> M       a\b\file.txt
> PS C:\Users\myuser\wc> cd a
> PS C:\Users\myuser\wc\a> svn st
> PS C:\Users\myuser\wc\a> cd b
> PS C:\Users\myuser\wc\a\b> svn st
> svn: warning: W155007: '.' is not a working copy
>
> Does anyone know why this is happening?  I searched for this problem
> and only found TortoiseSVN users complaining about it, and some
> suggestions to make sure the user has full control of the filesystem.
> I did this without resolution, but decided to post here since it is a
> Subversion issue (with Windows 7 perhaps) and not a TortoiseSVN issue.
>

It can happen because of wrong capitalization in the path.

Are "a" and "b" real names? Are you able to reproduce this with the
Greek tree (repro-template.bat) [1]? Did you do the checkout with
command-line client or with Tortoise?


AFAIK, Tortoise 1.7.3+ does some additional work to normalize paths
before passing them to Subversion library methods. (TSVN issue 156.
There was notorious bug in that code - issue 169. Fixed in TSVN 1.7.4
[2]).

In my experience Windows command shell also does some normalization
when I do "cd" command.


[1] http://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs
[2] http://code.google.com/p/tortoisesvn/issues/detail?id=156
http://code.google.com/p/tortoisesvn/issues/detail?id=169

Best regards,
Konstantin Kolinko

TortoiseSVN crash report (cleanup failed)

2012-01-29 Thread Ng, Alan 
As far as I can tell, the repository on this machine (which generated the 
error message copied below) got confused at some point in the past about 
upper/lowercase on one filename. My SourceForge repository has the filename 
all in lowercase, whereas this Windows machine had the corresponding file in 
uppercase. My attempts on this machine to synchronize or update the local 
repository with the SF repository failed. When I then manually deleted the 
Window file and attempted to synchronize or update, then SVN asks me to run 
cleanup first. Clean up attempts (involving the folder which had the offending 
uppercase file) then fail with this message:

---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
with as much information as possible about what
you were trying to do.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html

Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):

In file
 
'D:\Development\SVN\Releases\TortoiseSVN-1.7.4\ext\subversion\subversion\libsvn_wc\workqueue.c'
 line 673: assertion failed (checksum != 
NULL)---OK---

smime.p7s
Description: S/MIME cryptographic signature

RE: TortoiseSVN crash report (cleanup failed)

2012-01-29 Thread Ng, Alan 
Additional information: I discovered that the root of the problem was that
at some point in the past (months ago) the SourceForge repository got *both*
a lowercase and an uppercase version of the same filename. On Macs, svn
brought down only the uppercase file. On Windows XP, TortoiseSVN brought
down only the lowercase file. Presumably commits from both machines over
time got everything all mucked up.

This does suggest that some improvement could be made in SVN regarding
committing filenames differing only in case from what's already in the
repository.

> -Original Message-
> From: Ng, Alan
> Sent: Friday, January 27, 2012 2:19 PM
> To: 'users@subversion.apache.org'
> Subject: TortoiseSVN crash report (cleanup failed)
> 
> As far as I can tell, the repository on this machine (which generated the
> error message copied below) got confused at some point in the past about
> upper/lowercase on one filename. My SourceForge repository has the
filename
> all in lowercase, whereas this Windows machine had the corresponding file
in
> uppercase. My attempts on this machine to synchronize or update the local
> repository with the SF repository failed. When I then manually deleted the
> Window file and attempted to synchronize or update, then SVN asks me to
run
> cleanup first. Clean up attempts (involving the folder which had the
offending
> uppercase file) then fail with this message:
> 
> ---
> Subversion Exception!
> ---
> Subversion encountered a serious problem.
> Please take the time to report this on the Subversion mailing list
> with as much information as possible about what
> you were trying to do.
> But please first search the mailing list archives for the error message
> to avoid reporting the same problem repeatedly.
> You can find the mailing list archives at
> http://subversion.apache.org/mailing-lists.html
> 
> Subversion reported the following
> (you can copy the content of this dialog
> to the clipboard using Ctrl-C):
> 
> In file
>  'D:\Development\SVN\Releases\TortoiseSVN-
> 1.7.4\ext\subversion\subversion\libsvn_wc\workqueue.c' line 673: assertion
> failed (checksum !=
NULL)---OK---


smime.p7s
Description: S/MIME cryptographic signature

SVN 1.7.2 crashes immediately on start in APR xlate/xlate.c

2012-01-29 Thread Sebastian Magda 
Built and installed the latest stable version
subversion-1.7.2.tar.gz
Crashes immediately on start:

: svn
Segmentation fault (core dumped)

Build details:

: ./configure --with-ssl --with-apr=/usr/local/apache2
--with-apr-util=/usr/local/apache2 --with-apxs=/usr/local/apache2/bin/apxs
--enable-debug
: make
: make install
: which svn
/usr/local/bin/svn

System details:

: cat /etc/redhat-release
CentOS release 4.9 (Final)

: uname -mprsv
Linux 2.6.9-103.plus.c4smp #1 SMP Wed Dec 21 16:17:23 EST 2011 x86_64 x86_64

: gcc -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk
--host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-11)

:httpd -V
Server version: Apache/2.2.21 (Unix)
Server built:   Jan 26 2012 18:12:20
Server's Module Magic Number: 20051115:30
Server loaded:  APR 1.4.5, APR-Util 1.3.12
Compiled using: APR 1.4.5, APR-Util 1.3.12
Architecture:   64-bit
Server MPM: Prefork
  threaded: no
forked: yes (variable process count)
Server compiled with
 -D APACHE_MPM_DIR="server/mpm/prefork"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=128
 -D HTTPD_ROOT="/usr/local/apache2"
 -D SUEXEC_BIN="/usr/local/apache2/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_LOCKFILE="logs/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

Debugger details:

: ldd /usr/local/bin/svn
libsvn_client-1.so.0 => /usr/local/lib/libsvn_client-1.so.0
(0x002a95557000)
libsvn_wc-1.so.0 => /usr/local/lib/libsvn_wc-1.so.0
(0x002a956d)
libsvn_ra-1.so.0 => /usr/local/lib/libsvn_ra-1.so.0
(0x002a9588e000)
libsvn_diff-1.so.0 => /usr/local/lib/libsvn_diff-1.so.0
(0x002a9599b000)
libsvn_ra_local-1.so.0 => /usr/local/lib/libsvn_ra_local-1.so.0
(0x002a95ab1000)
libsvn_repos-1.so.0 => /usr/local/lib/libsvn_repos-1.so.0
(0x002a95bbb000)
libsvn_fs-1.so.0 => /usr/local/lib/libsvn_fs-1.so.0
(0x002a95cf4000)
libsvn_fs_fs-1.so.0 => /usr/local/lib/libsvn_fs_fs-1.so.0
(0x002a95dfe000)
libsvn_fs_util-1.so.0 => /usr/local/lib/libsvn_fs_util-1.so.0
(0x002a95f36000)
libsvn_ra_svn-1.so.0 => /usr/local/lib/libsvn_ra_svn-1.so.0
(0x002a96038000)
libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x003b9dc0)
libsvn_ra_neon-1.so.0 => /usr/local/lib/libsvn_ra_neon-1.so.0
(0x002a9617)
libsvn_delta-1.so.0 => /usr/local/lib/libsvn_delta-1.so.0
(0x002a962c4000)
libsvn_subr-1.so.0 => /usr/local/lib/libsvn_subr-1.so.0
(0x002a963d6000)
libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0
(0x002a96547000)
libaprutil-1.so.0 => /usr/local/apache2/lib/libaprutil-1.so.0
(0x002a966e)
libapr-1.so.0 => /usr/local/apache2/lib/libapr-1.so.0
(0x002a96802000)
libuuid.so.1 => /lib64/tls/libuuid.so.1 (0x003b9d80)
librt.so.1 => /lib64/tls/librt.so.1 (0x003ba0c0)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x003ba140)
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x003b9de0)
libssl.so.4 => /lib64/libssl.so.4 (0x003b9ff0)
libcrypto.so.4 => /lib64/libcrypto.so.4 (0x003b9f20)
libdl.so.2 => /lib64/libdl.so.2 (0x003b9da0)
libz.so.1 => /usr/lib64/libz.so.1 (0x003b9e00)
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2
(0x003b9f50)
libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x003b9f70)
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x003b9f00)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x003b9ec0)
libresolv.so.2 => /lib64/libresolv.so.2 (0x003b9e80)
libexpat.so.0 => /usr/lib64/libexpat.so.0 (0x003ba100)
libc.so.6 => /lib64/tls/libc.so.6 (0x003b9d50)
/lib64/ld-linux-x86-64.so.2 (0x003b9d30)

: gdb svn core.3020
GNU gdb Red Hat Linux (6.3.0.0-1.162.el4rh)
Copyright 2004 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 "x86_64

The content was displayed when i executed the command "update"

2012-01-29 Thread priest 
---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
with as much information as possible about what
you were trying to do.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html


Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):


In file
 
'D:\Development\SVN\Releases\TortoiseSVN-1.7.1\ext\subversion\subversion\libsvn_wc\update_editor.c'
 line 1582: assertion failed (action == svn_wc_conflict_action_edit || action
 == svn_wc_conflict_action_delete || action == svn_wc_conflict_action_replace)
---
确定   
---

Re: SVN 1.7.2 crashes immediately on start in APR xlate/xlate.c

2012-01-29 Thread Daniel Shahaf 
Sebastian Magda wrote on Sat, Jan 28, 2012 at 00:05:19 -0800:
> Built and installed the latest stable version
> subversion-1.7.2.tar.gz
> Crashes immediately on start:
> 
> : svn
> Segmentation fault (core dumped)
> 
> Build details:
> 
> : ./configure --with-ssl --with-apr=/usr/local/apache2
> --with-apr-util=/usr/local/apache2 --with-apxs=/usr/local/apache2/bin/apxs
> --enable-debug
> : make
> : make install
> : which svn
> /usr/local/bin/svn
...
> : gdb svn core.3020
> GNU gdb Red Hat Linux (6.3.0.0-1.162.el4rh)
> #0  apr_xlate_conv_buffer (convset=0x2d6674752d6e7673, inbuf=0x54da20 "Type
> 'svn help' for usage.\n", inbytes_left=0x7fbfffe508, outbuf=0x54da60 "",
> outbytes_left=0x7fbfffe500) at xlate/xlate.c:339
> 339 if (convset->ich != (iconv_t)-1) {
> 
> (gdb) bt
> #0  apr_xlate_conv_buffer (convset=0x2d6674752d6e7673, inbuf=0x54da20 "Type
> 'svn help' for usage.\n", inbytes_left=0x7fbfffe508, outbuf=0x54da60 "",
> outbytes_left=0x7fbfffe500) at xlate/xlate.c:339
> #1  0x002a96428a9d in convert_to_stringbuf (node=0x2a9643884a,
> src_data=0x54da20 "Type 'svn help' for usage.\n", src_length=27,
> dest=0x7fbfffe580, pool=0x54d278) at subversion/libsvn_subr/utf.c:540
> #2  0x002a9642925f in convert_cstring (dest=0x7fbfffe648, src=0x54da20
> "Type 'svn help' for usage.\n", node=0x2a9643884a, pool=0x54d278) at
> subversion/libsvn_subr/utf.c:774
> #3  0x002a96429804 in svn_utf_cstring_from_utf8 (dest=0x7fbfffe648,
> src=0x54da20 "Type 'svn help' for usage.\n", pool=0x54d278) at
> subversion/libsvn_subr/utf.c:908
> #4  0x002a963f2a3d in svn_cmdline_cstring_from_utf8 (dest=0x7fbfffe648,
> src=0x54da20 "Type 'svn help' for usage.\n", pool=0x54d278) at
> subversion/libsvn_subr/cmdline.c:244
> #5  0x002a963f2d34 in svn_cmdline_fputs (string=0x54da20 "Type 'svn
> help' for usage.\n", stream=0x3b9d733680, pool=0x54d278) at
> subversion/libsvn_subr/cmdline.c:323
> #6  0x002a963f2d0a in svn_cmdline_fprintf (stream=0x3b9d733680,
> pool=0x54d278, fmt=0x2a964360d2 "Type '%s help' for usage.\n") at
> subversion/libsvn_subr/cmdline.c:314
> #7  0x002a964121dc in svn_opt_print_help3 (os=0x0, pgm_name=0x425634
> "svn", print_version=0, quiet=0,
> version_footer=0x54d820 "The following repository access (RA) modules
> are available:\n\n* ra_neon : Module for accessing a repository via WebDAV
> protocol using Neon.\n  - handles 'http' scheme\n  - handles 'https'
> scheme\n* ra_svn"...,
> header=0x54d4c8 "usage: svn  [options] [args]\nSubversion
> command-line client, version 1.7.2.\nType 'svn help ' for help
> on a specific subcommand.\nType 'svn --version' to see the program version
> "..., cmd_table=0x537280, option_table=0x536840, global_options=0x427cc0,
> footer=0x7fbfffe880 "Subversion is a tool for version control.\nFor
> additional information, see http://subversion.apache.org/\n";,
> pool=0x54d278) at subversion/libsvn_subr/opt.c:1134
> #8  0x0040d6f2 in svn_cl__help (os=0x0, baton=0x0, pool=0x54d278)
> at subversion/svn/help-cmd.c:82
> #9  0x00412b0d in main (argc=1, argv=0x7fbfffef68) at
> subversion/svn/main.c:1523
> 
> (gdb) info locals
> status = 0
> 
> (gdb) info args
> convset = (apr_xlate_t *) 0x2d6674752d6e7673

% echo 2d6674752d6e7673 | xxd -p -r
-ftu-nvs
% fgrep \"svn-utf- subversion/*/*[hc] subversion/*[hc]
subversion/libsvn_subr/utf.c:static const char *SVN_UTF_NTOU_XLATE_HANDLE = 
"svn-utf-ntou-xlate-handle";
subversion/libsvn_subr/utf.c:static const char *SVN_UTF_UTON_XLATE_HANDLE = 
"svn-utf-uton-xlate-handle";
subversion/libsvn_subr/utf.c:  return apr_pstrcat(pool, "svn-utf-", frompage, 
"to", topage,

I don't recall offhand whether this was already fixed, though Philip
might remember.

> inbuf = 0x54da20 "Type 'svn help' for usage.\n"
> inbytes_left = (apr_size_t *) 0x7fbfffe508
> outbuf = 0x54da60 ""
> outbytes_left = (apr_size_t *) 0x7fbfffe500
> 
> My be related to this:
> http://svn.haxx.se/users/archive-2011-08/0210.shtml
> 

Yes, that 2d6674752d6e7673 value appears there too.

> Building with 'make CFLAGS=-O0' did not help.
> 
> Any help appreciated.
> 
> Sebastian Magda