[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: anyone else seen this assertion error?

From: Rick Jones <rick.jones2_at_hp.com>
Date: 2007-06-02 00:59:03 CEST

Karl Fogel wrote:
> Rick Jones <rick.jones2@hp.com> writes:
>
>>Transmitting file data ......svn:
>>/build/buildd/subversion-1.4.2dfsg1/subversion/libsvn_client/commit.c:1596:
>>svn_client_commit3: Assertion `*commit_info_p' failed.
>>Aborted
>>raj@tardy:~/netperf2_trunk$
>
>
> No. Is it reliably reproducible? (And if so, with latest trunk build?)

It is easily reproducible, I'm not sure about latest trunk build, the
server (netperf.org - parisc linux) and client (x86 system inside of HP)
are doing apt-gets to get the subversion bits. I was considering trying
a tot build but get nervous about that in just a fear uncertainty and
doubt kind of way.

Seems there is an open Debian bug #400099:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400099

which suggests there may be hook script errors involved. Indeed I have
a post-commit script for my repo that calls:

# Here is an example hook script, for a Unix /bin/sh interpreter:

REPOS="$1"
REV="$2"

echo $REPOS $REV >> /tmp/checklog
/usr/lib/subversion/hook-scripts/commit-email.pl -s "sandbox commit
notice" "$REPOS" "$REV" rick.jones2@hp.com

which _was_ working just fine and dandy until the update - actually a
full apt-get upgrade of the system.

The echo there was a recent thing because I couldn't recall the proper
parms. When I run commit-email.pl by hand per the script, it tells me I
need either a -h or --from option. Is that a comparatively "new"
requirement?

When I add a -h netperf.org, and run that commit-email.pl again by hand
I get:

www:/svn/sandbox/hooks# /usr/lib/subversion/hook-scripts/commit-email.pl
-s "test" /svn/sandbox 22 -h netperf.org rick.jones2@hp.com
Can't call method "mail" on an undefined value at
/usr/lib/subversion/hook-scripts/commit-email.pl line 605.

which I guess means I may have some perl issues?

>>and then after a while an svn status starts to claim certain files are
>>locked when I've not done anything of the sort:
>
>
> This "L"s don't refer to the repository-path locking feature, they are
> working copy administrative locks. 'svn cleanup' should take care of
> them.

Yep, that it does. It still leaves the working directory (wrong term
for the place to which I checked-out bits) thinking that the files I've
modified are not matching the repository - they still have "M's" even
though another svn co shows the mods went-in.

rick

>
> -Karl
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jun 2 00:59:33 2007

This is an archived mail posted to the Subversion Users mailing list.