You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Stein Somers <ss...@opnet.com> on 2009/09/10 14:00:18 UTC
Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt ||
cstr)
> 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: 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].