You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ryan Schmidt <su...@ryandesign.com> on 2009/05/19 10:01:11 UTC
Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr) (was: Re: (no subject))
On May 19, 2009, at 04:36, Diener, Christoph wrote:
> Ryan Schmidt wrote:
>
>> On May 19, 2009, at 03:30, Diener, Christoph wrote:
>>
>>> ---------------------------
>>> Subversion Exception!
>>> ---------------------------
>>> Subversion encountered a serious problem.
>>> Please take the time to report this on our mailing list
>>> with as much information as possible about what
>>> you were trying to do.
>>>
>>> Subversion reported the following:
>>>
>>> In file
>>> 'D:\Development\SVN\Releases\TortoiseSVN-1.6.1\ext\subversion
>>> \subversion\libsvn_ra_svn\marshal.c'
>>> line 486: assertion failed (opt || cstr)
>>> ---------------------------
>>> OK
>>> ---------------------------
>>
>> What were you doing before this problem occurred?
>> Can you reproduce it?
>> Have you already tried version 1.6.2?
> Hi Ray,
>
> sorry I'm not sure what I had done.
> I think it was an easy update, or commit which fails!? I had a tree
> conflict, after an cleanup it seems to be OK.
>
> Best Regards
> Christoph Diener
Ok. Maybe someone more familiar with the Subversion source code will
already know what to do about this error.
You didn't indicate whether you encountered the error only once or
multiple times, or whether you tried 1.6.2, but I recommend you
upgrade to 1.6.2 anyway since it is the latest version and may fix
bugs you might run into with 1.6.1.
P.S: Use Reply All so your reply goes to the list too, not just to me.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2309979
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr)
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Sep 16, 2009 at 02:24:04PM +0100, Stefan Sperling wrote:
> On Wed, Sep 16, 2009 at 10:23:57AM +0200, Bert Huijben wrote:
> > Can you try reproducing it without maintainer mode?
>
> Works, with tags/1.6.5.
And merging r39362 makes the assertion failure go away.
Nominated for backport to 1.6.x.
Thanks Bert, and especially Stein, for helping with this!
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395571
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr)
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Sep 16, 2009 at 10:23:57AM +0200, Bert Huijben wrote:
> Can you try reproducing it without maintainer mode?
Works, with tags/1.6.5.
+ svn revert issue-3485/trunk2/alpha
Reverted 'issue-3485/trunk2/alpha'
+ svn up issue-3485/trunk2
svn: In file 'subversion/libsvn_ra_svn/marshal.c' line 486: assertion failed (op
t || cstr)
Abort trap (core dumped)
Here's the stack trace for anyone interested:
#0 0x0b9a8289 in kill () from /usr/lib/libc.so.51.0
#1 0x0b9f4fef in abort () at /usr/src/lib/libc/stdlib/abort.c:68
#2 0x060770e9 in svn_error_abort_on_malfunction (can_return=1,
file=0x231184e0 "subversion/libsvn_ra_svn/marshal.c", line=486,
expr=0x23118649 "opt || cstr") at subversion/libsvn_subr/error.c:525
#3 0x0607712f in svn_error__malfunction (can_return=1,
file=0x231184e0 "subversion/libsvn_ra_svn/marshal.c", line=486,
expr=0x23118649 "opt || cstr") at subversion/libsvn_subr/error.c:548
#4 0x031227ac in vwrite_tuple (conn=0x82d81340, pool=0x8b44f018,
fmt=0x231186d5 "cn", ap=0xcfbd2aec "")
at subversion/libsvn_ra_svn/marshal.c:488
#5 0x031228a8 in svn_ra_svn_write_tuple (conn=0x82d81340, pool=0x8b44f018,
fmt=0x231186d3 "nccn") at subversion/libsvn_ra_svn/marshal.c:527
#6 0x0312382a in svn_ra_svn_write_cmd_failure (conn=0x82d81340,
pool=0x8b44f018, err=0x86242058) at subversion/libsvn_ra_svn/marshal.c:1007
#7 0x031214fe in svn_ra_svn_drive_editor2 (conn=0x82d81340, pool=0x862420a8,
editor=0x866806c0, edit_baton=0x86680700, aborted=0x0, for_replay=0)
at subversion/libsvn_ra_svn/editorp.c:902
#8 0x0311ab26 in ra_svn_finish_report (baton=0x86680840, pool=0x86680018)
at subversion/libsvn_ra_svn/client.c:289
#9 0x00847652 in svn_wc_crawl_revisions4 (
path=0x88085818 "issue-3485/trunk2", adm_access=0x866801c8,
reporter=0x231197ac, report_baton=0x86680840, restore_files=1,
depth=svn_depth_unknown, honor_depth_exclude=1,
depth_compatibility_trick=0, use_commit_times=0,
notify_func=0x1c00be6c <notify>, notify_baton=0x88085860,
traversal_info=0x86680058, pool=0x86680018)
at subversion/libsvn_wc/adm_crawler.c:748
#10 0x0a56d704 in svn_client__update_internal (result_rev=0xcfbd2da4,
path=0x88085818 "issue-3485/trunk2", revision=0xcfbd2f14,
depth=svn_depth_unknown, depth_is_sticky=0, ignore_externals=0,
allow_unver_obstructions=0, timestamp_sleep=0xcfbd2da8,
send_copyfrom_args=1, ctx=0x885d77b8, pool=0x86680018)
at subversion/libsvn_client/update.c:263
#11 0x0a56da54 in svn_client_update3 (result_revs=0x0, paths=0x88085830,
revision=0xcfbd2f14, depth=svn_depth_unknown, depth_is_sticky=0,
ignore_externals=0, allow_unver_obstructions=0, ctx=0x885d77b8,
pool=0x885d7018) at subversion/libsvn_client/update.c:346
#12 0x1c00fe0a in svn_cl__update (os=0x885d71c0, baton=0x0, pool=0x885d7018)
---Type <return> to continue, or q <return> to quit---
at subversion/svn/update-cmd.c:90
#13 0x1c00a9eb in main (argc=1, argv=0xcfbd30ac) at subversion/svn/main.c:2123
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395506
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr)
Posted by Bert Huijben <rh...@sharpsvn.net>.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: dinsdag 15 september 2009 20:06
> To: Stein Somers
> Cc: users@subversion.tigris.org
> Subject: Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
> cstr)
>
> On Tue, Sep 15, 2009 at 06:45:00PM +0200, Stein Somers wrote:
> > Stefan Sperling wrote:
> > > Which version are you reproducing the marshal.c assertion with?
> >
> > The stable 1.6.5: summersoft rhel5 packages on Linux, SlikSVN on
> Windows.
> >
> > > Both 1.6.x and trunk give the following output for me:
> >
> > My output is the same until the last step, apart from irrelevant
> details.
> > The last step is:
> >
> > + svn up bug2/trunk2
> > svn: In file 'subversion/libsvn_ra_svn/marshal.c' line 486: assertion
> failed
> > (opt || cstr)
> > bug2.sh: line 41: 20884 Aborted svn up ${trunk}2
>
> I cannot reproduce it with 1.6.5 either :(
>
> I guess we'll have to wait for someone else to reproduce this.
> I've filed an issue and attached your reproduction script there.
> http://subversion.tigris.org/issues/show_bug.cgi?id=3485
Can you try reproducing it without maintainer mode?
In r39197 I fixed an issue where transferring errors from client to server
and vice versa might cause this exception.
But with maintainer mode it is far less likely to occur.
If no filename was attached to an error message the ra layer tried to
transfer a NULL, which could cause this assertion to fail.
Bert
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395396
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr)
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Sep 15, 2009 at 06:45:00PM +0200, Stein Somers wrote:
> Stefan Sperling wrote:
> > Which version are you reproducing the marshal.c assertion with?
>
> The stable 1.6.5: summersoft rhel5 packages on Linux, SlikSVN on Windows.
>
> > Both 1.6.x and trunk give the following output for me:
>
> My output is the same until the last step, apart from irrelevant details.
> The last step is:
>
> + svn up bug2/trunk2
> svn: In file 'subversion/libsvn_ra_svn/marshal.c' line 486: assertion failed
> (opt || cstr)
> bug2.sh: line 41: 20884 Aborted svn up ${trunk}2
I cannot reproduce it with 1.6.5 either :(
I guess we'll have to wait for someone else to reproduce this.
I've filed an issue and attached your reproduction script there.
http://subversion.tigris.org/issues/show_bug.cgi?id=3485
Thanks a bunch for your help!
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395192
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr)
Posted by Stein Somers <ss...@opnet.com>.
Stefan Sperling wrote:
> Which version are you reproducing the marshal.c assertion with?
The stable 1.6.5: summersoft rhel5 packages on Linux, SlikSVN on Windows.
> Both 1.6.x and trunk give the following output for me:
My output is the same until the last step, apart from irrelevant details.
The last step is:
+ svn up bug2/trunk2
svn: In file 'subversion/libsvn_ra_svn/marshal.c' line 486: assertion failed
(opt || cstr)
bug2.sh: line 41: 20884 Aborted svn up ${trunk}2
--
Stein
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395157
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr)
Posted by Stein Somers <ss...@opnet.com>.
Stein Somers wrote:
> However, if instead of this conflict, working had scheduled an add, and
> the updates include an add of the same file, then a revert currently
> leaves some poo behind.
Sorry, at this point I realized it was easy enough to test, but a freak
meteorite fell out the sky right on the send button. I cannot find any kind
of poo doing this with 1.6.5.
--
Stein
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395483
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr)
Posted by Stein Somers <ss...@opnet.com>.
Stefan Sperling wrote:
> + svn st issue-3485/trunk2
> A + issue-3485/trunk2/alpha
>
> Usually, people would commit at this point.
Or people would revert the file, if their intention is to say
resolved-using-theirs, or "they are right, deleting the crummy file is a
better idea than repairing it". From your description, I gather at this stage
"revert" works fine even instead of resolving. In the context of an update,
"revert" = "resolve-using-theirs". Except that it leaves an unversioned file
behind, in the case you edited it and they deleted it, but that's quite all
right.
However, if instead of this conflict, working had scheduled an add, and the
updates include an add of the same file, then a revert currently leaves some
poo behind.
--
Stein Somers
Principal Software Engineer, Optical Solutions
OPNET Technologies bvba http://www.opnet.com/
Franklin Rooseveltlaan 348 W, B-9000 Gent, Belgium
skype: steinsomers
phone: +32 92 65 02 41 (indirect and only 9AM-5PM WET)
fax: +32 92 65 02 17
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395407
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr)
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
[...]
> And thanks for reading up to here! If you understood all of the above
> please consider contributing patches :)
heh, stsp ;)
Thanks for the tour, it was written out very nicely.
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395246
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr)
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Sep 15, 2009 at 08:33:51PM +0200, Stein Somers wrote:
> Stefan Sperling wrote:
> > subversion/svn/update-cmd.c:96: (apr_err=210000)
> > subversion/libsvn_client/update.c:371: (apr_err=210000)
> > subversion/libsvn_client/update.c:294: (apr_err=210000)
> > subversion/libsvn_wc/deprecated.c:149: (apr_err=210000)
> > subversion/libsvn_ra_svn/client.c:296: (apr_err=210000)
> > subversion/svnserve/serve.c:851: (apr_err=210000)
> > svn: Special code for wrapping server errors to report to client
> > subversion/libsvn_wc/update_editor.c:2001: (apr_err=150000)
> > subversion/libsvn_wc/entries.c:1325: (apr_err=150000)
> > svn: 'bug2/trunk2/alpha' is not under version control
>
> One thing that puzzles me: svn sends all this gibberish your way, but you say
> you can't reproduce the problem?
Most of this gibberish is there because I've compiled with
--enable-maintainer-mode.
> Seems to me you don't see the devil in the
> shape I do, but you do see the problem that the state of the working copy
> causes the last svn update to bark at you.
You're right that there might be another bug here. But my main goal was to
see the same assertion as you saw. And since I'm not getting that,
I cannot reproduce that particular problem.
But yes, let's look at what I am seeing.
We start with a locally modified file which is based on an out-of-date
revision, r1. HEAD is r2.
+ svn stat issue-3485/trunk2
M issue-3485/trunk2/alpha
Then we update and find out that the file been deleted in r2:
+ svn up issue-3485/trunk2
C issue-3485/trunk2/alpha
At revision 2.
Summary of conflicts:
Tree conflicts: 1
+ svn st issue-3485/trunk2
A + C issue-3485/trunk2/alpha
> local edit, incoming delete upon update
We decide to keep our version of the file by keeping it added,
so we mark the working state as resolved.
The file was scheduled to be added during tree conflict detection because
this makes it easier to keep files which were locally modified but
deleted in the repository.
+ svn resolved issue-3485/trunk2/alpha
Resolved conflicted state of 'issue-3485/trunk2/alpha'
+ svn st issue-3485/trunk2
A + issue-3485/trunk2/alpha
Usually, people would commit at this point.
But we want to trigger the opt || cstr assertion.
So we are mad and continue wrecking the working copy...
So now we update the entire WC down to r1 again, which added the
file we now happen to also have scheduled for addition:
+ svn up -r1 --force issue-3485/trunk2
C issue-3485/trunk2/alpha
At revision 1.
Summary of conflicts:
Tree conflicts: 1
+ svn st issue-3485/trunk2
A + C issue-3485/trunk2/alpha
> local add, incoming add upon update
Svn has seen a local add vs. an incoming add. That's correct.
Now we start seeing problems:
Reverting a locally added file will make it unversioned.
Unversioning a file means removing its meta data from the .svn/entries.
The revert does not pay attention to the state of our parent directory.
The server has the file in r1, but the client's WC is also supposed
to be at r1, but it has now lost the file.
I actually had to ask Erik Hülsmann for help on understanding this:
<ehu`> well, if this item is not locally available, but the server
has it in its tree, then there's a state mismatch: the client
should at least have it marked as "missing"
<stsp> yeah
<stsp> the revert should have done that?
<ehu`> I think so. the update could have done it, but then it destroys
the state which caused the conflict.
<stsp> so revert is currently too stupid
<ehu`> yea.
Revert also happens to clear the tree conflict markers unconditionally.
This behaviour is probably not ideal either.
+ svn revert issue-3485/trunk2/alpha
Reverted 'issue-3485/trunk2/alpha'
+ svn st issue-3485/trunk2
? issue-3485/trunk2/alpha
Now we run a normal "svn update", and this is the state after the update:
+ svn st issue-3485/trunk2
! issue-3485/trunk2
? issue-3485/trunk2/alpha
The exclamation mark means that the directory is marked "incomplete".
libsvn_wc/README tells us:
incomplete:
A boolean: true if this entries file is not complete yet. Used
when updating. This is only allowed on the this_dir entry; it
allows update operations to be non-atomic, by marking the directory
as still in the process of being updated. If this update is
interrupted for some reason, a later update will see that this
directory is incomplete and Do The Right Thing.
So yes, a revert leaving a directory behind in inconsistent state,
causing an update to bail out early and leaving the directory behind
in an incomplete state is a bug. But it's an entirely different
problem than what we were looking at, which was in the svn:// protocol
code, not the working copy code.
But thanks for bringing this up. I will try to think about this more
and find a way to fix 'svn revert'.
And thanks for reading up to here! If you understood all of the above
please consider contributing patches :)
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395224
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr)
Posted by Stein Somers <ss...@opnet.com>.
Stefan Sperling wrote:
> subversion/svn/update-cmd.c:96: (apr_err=210000)
> subversion/libsvn_client/update.c:371: (apr_err=210000)
> subversion/libsvn_client/update.c:294: (apr_err=210000)
> subversion/libsvn_wc/deprecated.c:149: (apr_err=210000)
> subversion/libsvn_ra_svn/client.c:296: (apr_err=210000)
> subversion/svnserve/serve.c:851: (apr_err=210000)
> svn: Special code for wrapping server errors to report to client
> subversion/libsvn_wc/update_editor.c:2001: (apr_err=150000)
> subversion/libsvn_wc/entries.c:1325: (apr_err=150000)
> svn: 'bug2/trunk2/alpha' is not under version control
One thing that puzzles me: svn sends all this gibberish your way, but you say
you can't reproduce the problem? Seems to me you don't see the devil in the
shape I do, but you do see the problem that the state of the working copy
causes the last svn update to bark at you.
--
Stein
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395204
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr)
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Sep 15, 2009 at 05:06:43PM +0200, Stein Somers wrote:
> Stefan Sperling wrote:
> > At which point do you get the failure?
>
> The last step, the update.
>
> > this script (which I hope is equivalent to what you were doing):
>
> It's different in that:
> - it forgets to cause a tree conflict, so not much point in resolving
> - it has the revision numbers off by one, because my revision 1 was the
> creation of the top directory.
>
> With the following variation of your script I have the same assertion abort
> on CentOS 5:
Thanks!
Which version are you reproducing the marshal.c assertion with?
Both 1.6.x and trunk give the following output for me:
+ rm -rf bug2
+ mkdir -p bug2
+ mkdir -p bug2/trunk
+ echo alpha
+ > bug2/trunk/alpha
+ echo beta
+ > bug2/trunk/beta
+ svnadmin create /tmp/bug2/repos
+ svn import bug2/trunk file:////tmp/bug2/repos/trunk -m importing project tree
Adding bug2/trunk/alpha
Adding bug2/trunk/beta
Committed revision 1.
+ rm -rf bug2/trunk
+ svn checkout file:////tmp/bug2/repos/trunk bug2/trunk
A bug2/trunk/alpha
A bug2/trunk/beta
Checked out revision 1.
+ svn rm bug2/trunk/alpha
D bug2/trunk/alpha
+ svn ci -mm bug2/trunk
Deleting bug2/trunk/alpha
Committed revision 2.
+ svnserve --pid-file bug2/svnserve.pid --listen-host localhost --listen-port 36900 -d -r bug2/repos
+ cat bug2/svnserve.pid
+ trap kill 24985 0
+ svn co svn://localhost:36900/trunk@1 bug2/trunk2
A bug2/trunk2/alpha
A bug2/trunk2/beta
Checked out revision 1.
+ ls -l bug2/trunk2/alpha
-rw-r--r-- 1 stsp wheel 6 Sep 15 17:03 bug2/trunk2/alpha
+ echo gamma
+ > bug2/trunk2/alpha
+ ls -l bug2/trunk2/alpha
-rw-r--r-- 1 stsp wheel 6 Sep 15 17:03 bug2/trunk2/alpha
+ svn stat bug2/trunk2
M bug2/trunk2/alpha
+ svn up bug2/trunk2
C bug2/trunk2/alpha
At revision 2.
Summary of conflicts:
Tree conflicts: 1
+ svn resolved bug2/trunk2/alpha
Resolved conflicted state of 'bug2/trunk2/alpha'
+ svn up -r1 --force bug2/trunk2
C bug2/trunk2/alpha
At revision 1.
Summary of conflicts:
Tree conflicts: 1
+ svn revert bug2/trunk2/alpha
Reverted 'bug2/trunk2/alpha'
+ svn up bug2/trunk2
subversion/svn/update-cmd.c:96: (apr_err=210000)
subversion/libsvn_client/update.c:371: (apr_err=210000)
subversion/libsvn_client/update.c:294: (apr_err=210000)
subversion/libsvn_wc/deprecated.c:149: (apr_err=210000)
subversion/libsvn_ra_svn/client.c:296: (apr_err=210000)
subversion/svnserve/serve.c:851: (apr_err=210000)
svn: Special code for wrapping server errors to report to client
subversion/libsvn_wc/update_editor.c:2001: (apr_err=150000)
subversion/libsvn_wc/entries.c:1325: (apr_err=150000)
svn: 'bug2/trunk2/alpha' is not under version control
+ kill 24985
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395143
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr)
Posted by Stein Somers <ss...@opnet.com>.
Stefan Sperling wrote:
> At which point do you get the failure?
The last step, the update.
> this script (which I hope is equivalent to what you were doing):
It's different in that:
- it forgets to cause a tree conflict, so not much point in resolving
- it has the revision numbers off by one, because my revision 1 was the
creation of the top directory.
With the following variation of your script I have the same assertion abort
on CentOS 5:
#!/bin/sh
set -eu
cwd=`pwd`
basename=`basename $0`
scratch_area="`echo $basename | sed -e s/\.sh$//`"
repos=$scratch_area/repos
trunk=$scratch_area/trunk
trunk_url=file:///$cwd/$repos/trunk
set -x
rm -rf $scratch_area
mkdir -p $scratch_area
mkdir -p $trunk
echo alpha > $trunk/alpha
echo beta > $trunk/beta
svnadmin create $cwd/$repos
svn import $trunk $trunk_url -m "importing project tree"
rm -rf $trunk
svn checkout $trunk_url $trunk
svn rm $trunk/alpha
svn ci -mm $trunk
svnserve --pid-file $scratch_area/svnserve.pid \
--listen-host localhost --listen-port 36900 -d -r $repos
trap "kill `cat $scratch_area/svnserve.pid`" 0
svn co svn://localhost:36900/trunk@1 ${trunk}2
ls -l ${trunk}2/alpha
echo gamma > ${trunk}2/alpha
ls -l ${trunk}2/alpha
svn stat ${trunk}2
svn up ${trunk}2
svn resolved ${trunk}2/alpha
svn up -r1 --force ${trunk}2
svn revert ${trunk}2/alpha
svn up ${trunk}2
--
Stein
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395117
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr)
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Sep 10, 2009 at 04:00:18PM +0200, Stein Somers wrote:
> > Can you provide a command-line transcript of what you did exactly?
>
> I'm happy to say I can. I struggled a bit and in fact the first error I saw
> was "svn: Checksum mismatch while updating ..." (I haven't fooled around in
> .svn directories), but that one I didn't reproduce.
>
> From the ground up, this is how I prepared the repository:
> On server:
> > svnadmin create sandbox
> edit password in sandbox/conf/svnserve.conf
>
> On client:
> # created sandbox/ssomers using TSVN repo browser
> svn co svn://server/sandbox/ssomers sandbox
> cd sandbox
> echo a>a
> echo b>b
> svn add a b
> svn commit -m start
> svn up
> svn del a
> svn commit -m new
>
> such that revision 2 has 2 files and HEAD deletes one of them.
>
> Then we can reproduce:
> svn co svn://server/sandbox/ssomers@2 final
> cd final
> echo c>a
> svn up # gives conflict
> svn resolved a
> svn up -r2 --force # gives conflict
> svn revert a
> svn up
>
> This is a mean sequence of events looking at it now, but I was just trying to
> get work done. I use TortoiseSVN often and I wasn't aware that "Update to
> revision" includes --force.
At which point do you get the failure?
I cannot reproduce this on BSD with svn trunk or 1.6.x using
this script (which I hope is equivalent to what you were doing):
#!/bin/sh
set -e
cwd=`pwd`
basename=`basename $0`
scratch_area="`echo $basename | sed -e s/\.sh$//`"
repos=$scratch_area/repos
trunk=$scratch_area/trunk
trunk_url=file:///$cwd/$repos/trunk
set -x
rm -rf $scratch_area
mkdir -p $scratch_area
mkdir -p $trunk
echo alpha > $trunk/alpha
echo beta > $trunk/beta
svnadmin create $cwd/$repos
svn import $trunk $trunk_url -m "importing project tree"
rm -rf $trunk
svn checkout $trunk_url $trunk
svn rm $trunk/alpha
svn ci -mm $trunk
svnserve --pid-file $scratch_area/svnserve.pid \
--listen-host localhost -d -r $repos
svn co svn://localhost/trunk@2 ${trunk}2
svn up ${trunk}2
svn resolved ${trunk}2/alpha
svn up -r2 --force ${trunk}2
svn revert ${trunk}2/alpha
svn up ${trunk}2
kill `cat $scratch_area/svnserve.pid`
The output is:
+ rm -rf bug
+ mkdir -p bug
+ mkdir -p bug/trunk
+ echo alpha
+ > bug/trunk/alpha
+ echo beta
+ > bug/trunk/beta
+ svnadmin create /tmp/bug/repos
+ svn import bug/trunk file:////tmp/bug/repos/trunk -m importing project tree
Adding bug/trunk/alpha
Adding bug/trunk/beta
Committed revision 1.
+ rm -rf bug/trunk
+ svn checkout file:////tmp/bug/repos/trunk bug/trunk
A bug/trunk/alpha
A bug/trunk/beta
Checked out revision 1.
+ svn rm bug/trunk/alpha
D bug/trunk/alpha
+ svn ci -mm bug/trunk
Deleting bug/trunk/alpha
Committed revision 2.
+ svnserve --pid-file bug/svnserve.pid --listen-host localhost -d -r bug/repos
+ svn co svn://localhost/trunk@2 bug/trunk2
A bug/trunk2/beta
Checked out revision 2.
+ svn up bug/trunk2
At revision 2.
+ svn resolved bug/trunk2/alpha
+ svn up -r2 --force bug/trunk2
At revision 2.
+ svn revert bug/trunk2/alpha
Skipped 'bug/trunk2/alpha'
+ svn up bug/trunk2
At revision 2.
+ cat bug/svnserve.pid
+ kill 14255
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395096
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr)
Posted by Stein Somers <ss...@opnet.com>.
> Can you provide a command-line transcript of what you did exactly?
I'm happy to say I can. I struggled a bit and in fact the first error I saw
was "svn: Checksum mismatch while updating ..." (I haven't fooled around in
.svn directories), but that one I didn't reproduce.
From the ground up, this is how I prepared the repository:
On server:
> svnadmin create sandbox
edit password in sandbox/conf/svnserve.conf
On client:
# created sandbox/ssomers using TSVN repo browser
svn co svn://server/sandbox/ssomers sandbox
cd sandbox
echo a>a
echo b>b
svn add a b
svn commit -m start
svn up
svn del a
svn commit -m new
such that revision 2 has 2 files and HEAD deletes one of them.
Then we can reproduce:
svn co svn://server/sandbox/ssomers@2 final
cd final
echo c>a
svn up # gives conflict
svn resolved a
svn up -r2 --force # gives conflict
svn revert a
svn up
This is a mean sequence of events looking at it now, but I was just trying to
get work done. I use TortoiseSVN often and I wasn't aware that "Update to
revision" includes --force.
--
Stein
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393259
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr) (was: Re: (no subject))
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Sep 10, 2009 at 02:21:08AM -0700, Stein Somers wrote:
> I encountered the same after a relatively short sequence in a new working copy. Server and client are version 1.6.5. I did not try to reproduce this but I will if someone wants to. The steps were IIRC:
> 1. check out a particular revision
> 2. edit one of the files, say "foo"
> 3. update to a later revision, which involves deleting the file foo. This gave a conflict. I left the conflict and foo the way it was and forgot about it.
> 4. try to update back to the earlier revision. Tree conflict, of course. Resolved using "theirs" but now file foo is still unversioned. Delete file foo from the file system and try again to update to the earlier revision. Nothing changes, foo does not reappear.
You cannot resolve a tree conflict using "theirs".
You can only resolve it to "working".
Can you provide a command-line transcript of what you did exactly?
Human-language descriptions are nice but not 100% reliable in
communicating exactly what commands need to be typed to trigger
the problem.
Thanks,
Stefan
> 5. So let's try to correct things by doing step 3 and 4 again. Alas now step 4 crashes with the exception.
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393185
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393223
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr) (was: Re: (no subject))
Posted by Stein Somers <ss...@opnet.com>.
I encountered the same after a relatively short sequence in a new working copy. Server and client are version 1.6.5. I did not try to reproduce this but I will if someone wants to. The steps were IIRC:
1. check out a particular revision
2. edit one of the files, say "foo"
3. update to a later revision, which involves deleting the file foo. This gave a conflict. I left the conflict and foo the way it was and forgot about it.
4. try to update back to the earlier revision. Tree conflict, of course. Resolved using "theirs" but now file foo is still unversioned. Delete file foo from the file system and try again to update to the earlier revision. Nothing changes, foo does not reappear.
5. So let's try to correct things by doing step 3 and 4 again. Alas now step 4 crashes with the exception.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393185
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr) (was: Re: (no subject))
Posted by Johan Corveleyn <jo...@uz.kuleuven.ac.be>.
Hi Omar,
You probably ran into this issue: http://subversion.tigris.org/issues/show_bug.cgi?id=3485
It is fixed in 1.6.6, so if you upgrade your TortoiseSVN to 1.6.6 you won't run into it again.
Regards,
Johan
> -----Oorspronkelijk bericht-----
> Van: Omar [mailto:omar@miracleworld.net]
> Verzonden: vrijdag 18 december 2009 7:55
> Aan: users@subversion.tigris.org
> Onderwerp: RE: Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
> cstr) (was: Re: (no subject))
>
> Hello,
>
> I just had the same error today while working and found this thread by
> Googling the message.
>
> I am working under Windows XP via the frontend TortoiseSVN 1.6.2 build 16344,
> 32-bits, based on Subversion 1.6.2. I've been using this setup since one year
> with no similar trouble (updating TortoiseSVN every few months).
>
> I am currently refactoring a lot of code for the purpose of a new project so
> it is a bit difficult to know exactly what I did to cause the error. Roughly
> the sequence of events what:
>
> (modify various files in project1/)
> (modify various files in project2/)
> svn move project1/file1 lib1/file1
> svn delete project2/file1
> svn commit
> (commit failed because of remotely updated file in project1/)
> svn update
>
> The assert appeared during update (I took a screenshot immediately, it is
> attached). After closing the box I updated again and I got a message saying
> that the project2/ tree was conflicted (not sure of the exact term, it
> appeared red in TortoiseSVN interface). I quickly checked its content and did
> a Resolve on it and it appears to be working now. I could commit and continue
> my work from then.
>
> I am sorry my report isn't more clear. If you have specific questions maybe I
> can remember more of the details.
>
> Thanks,
> -Omar
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2431410
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
RE: Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr) (was: Re: (no subject))
Posted by Omar <om...@miracleworld.net>.
Hello,
I just had the same error today while working and found this thread by Googling the message.
I am working under Windows XP via the frontend TortoiseSVN 1.6.2 build 16344, 32-bits, based on Subversion 1.6.2. I've been using this setup since one year with no similar trouble (updating TortoiseSVN every few months).
I am currently refactoring a lot of code for the purpose of a new project so it is a bit difficult to know exactly what I did to cause the error. Roughly the sequence of events what:
(modify various files in project1/)
(modify various files in project2/)
svn move project1/file1 lib1/file1
svn delete project2/file1
svn commit
(commit failed because of remotely updated file in project1/)
svn update
The assert appeared during update (I took a screenshot immediately, it is attached). After closing the box I updated again and I got a message saying that the project2/ tree was conflicted (not sure of the exact term, it appeared red in TortoiseSVN interface). I quickly checked its content and did a Resolve on it and it appears to be working now. I could commit and continue my work from then.
I am sorry my report isn't more clear. If you have specific questions maybe I can remember more of the details.
Thanks,
-Omar