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