issues@subversion.tigris.org writes:
> + ------- Additional Comments From jgoerzen@tigris.org 2003-05-02 13:22 PDT -------
> + Regarding the commit...
> +
> + No properties were changed.
> +
> + This commit was generated by svn_load_dirs loading Linux kernel version
> + 2.5.67 over version 2.5.66 into the repository. To accomplish that load,
> + svn_load_dirs does two commits. The first commits renames and new
> + directories that need to be added, etc. That commit succeeded without
> + difficulty.
I don't know much about svn_load_dirs, after the first commit does the
working copy still have local modifications? Does it run update after
the commit?
> + It is the second commit that is failing. I have also been able to
> + consistently reproduce this by just running an svn commit over the working
> + directory that svn_load_dirs left.
So 'svn status' before the commit could contain modified/added/deleted
files and deleted directories? How many: a few, dozens, hundreds?
Does the commit command specify a single directory target, or are
there multiple targets?
> + I am fairly confident that this is not a bug in svn_load_dirs, as I have loaded
> + literally hundreds of Linux revs using this procedure. One thing that has
> + changed is that I am now accessing a remote svnserve machine that is
> + being a little flaky rather than a local repository.
> +
> + I wouldn't be surprised if the remote server was doing something wacky or
> + wrong. However, I can't tell what's going on because the client is
> + segfaulting before handing me the error.
How do you know there is an error? Is it because the commit fails on
the server side? In the debugger you should be able to go up the call
stack to svn_client_commit and then display the cmt_err variable which
should contain any error.
> + I've written a little about the problems we've been having with the server in
> + the dev list.
Probably I missed that mail.
If valgrind is available on the client machine you could try
valgrind svn commit [svn_arg ...]
and see if that produces any warnings. You can use
valgrind --gdb-attach=yes svn commit [svn_arg ...]
if you want to debug any problems that are reported.
Another thing you could do is to try committing a subset of the
working copy, you may be able to identify a smaller testcase that
causes the problem. (Anyone else wanting to debug this problem needs
both a repository and a working copy, and I assume they are large.)
One obvious thing to try is to use a different RA method, if that is
possible.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 3 01:36:36 2003