Re: A question about committing a deleted file
Running update on the working copy after that commit will automatically remove the lock from the working copy. (An update between the stealing of the lock and the delete would do the same thing). When a node is deleted from the working copy during update or switch your client can't be sure why that happened (you might have updated to a revision I'm which that file doesn't exist). Just removing the lock token from a wc when it might still be valid is a bigger issue, than not noticing that a lock is stolen. Stealing a lock was never intended to be a common operation as it breaks the entire idea of using locks. Bert From: Zi Wang Sent: Friday, March 14, 2014 8:49 PM To: users@subversion.apache.org Hello, please help me to understand this: Here is the scenario: Two person A and B are working on the same project and both have a working copy on their machine, A: Lock(check out) a file, call it FILE_X B: Break FILE_X's lock, then Delete FILE_X and Commit A: Update (now FILE_X is gone on A's working copy), then Add a new file also called FILE_X, then Commit Now, at this point, FILE_X on A's working copy will have a Lock, even though it was a new file just with the same name, how come? Does SVN remembers the status? If so, is there a way to tell SVN to 'forgot' the status? Thank you!
Re: Bug report: svn assert failure: svn: subversion/libsvn_client/merge.c:3128: merge_dir_deleted: Assertion `delb != ((void *)0)' failed.
Did you read the documentation about adding issues? Adding an issue isn't part of the process of getting an issue resolved. So, do you want to be able to find it in a few years? Or do you want to see it fixed? If you only want to see it remembered, you can add an issue. But if you want to have it resolved you should discuss the issue here. That will cause somebody to actually look at it, while adding an issue doesn’t. (I can't look at it now as I can't open your .sh attachment now; and you don't tell anything about the actual problem in your mail) Just adding an issue will just slow the process of resolving your issue. That is why we have the rule of discussing it on the list… Bert From: Danilo Piazzalunga Sent: Friday, March 14, 2014 10:53 PM To: users@subversion.apache.org Hi all, I am asking for confirmation before reporting a bug Using Subversion 1.8.8 installed from Ubuntu 14.04 packages, svn crashed while performing a merge operation involving a replaced directory. I already reportted this bug to Ubuntu Launchpad as https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1288829 I was able to reproduce the bug with Subversion 1.9.0-dev trunk (r1577730) with a self-contained test case (see attachment). Can I report this to the Issue Tracker? Regards, Danilo Piazzalunga
Re: Bug report: svn assert failure: svn: subversion/libsvn_client/merge.c:3128: merge_dir_deleted: Assertion `delb != ((void *)0)' failed.
On Fri, Mar 14, 2014 at 10:53:05PM +0100, Danilo Piazzalunga wrote: > Hi all, > I am asking for confirmation before reporting a bug > > Using Subversion 1.8.8 installed from Ubuntu 14.04 packages, svn > crashed while performing a merge operation involving a replaced > directory. > > I already reportted this bug to Ubuntu Launchpad as > https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1288829 > > I was able to reproduce the bug with Subversion 1.9.0-dev trunk > (r1577730) with a self-contained test case (see attachment). > > Can I report this to the Issue Tracker? I can reproduce this crash using your script, with 1.8 and trunk. Please file an issue. Thanks! Backtrace using a trunk client: ### Merge from trunk. assertion "delb != NULL" failed: file "subversion/libsvn_client/merge.c", line 3128, function "merge_dir_deleted" Abort trap (core dumped) #1 0x045fa5c1999a in abort () at /usr/src/lib/libc/stdlib/abort.c:70 #2 0x045fa5b97414 in __assert2 (file=Variable "file" is not available. ) at /usr/src/lib/libc/gen/assert.c:52 #3 0x045fa3e27486 in merge_dir_deleted (relpath=0x45fa2d5f0b0 "A/D/G", left_source=0x45f9b03c300, left_props=0x45f9b03c368, dir_baton=0x45f9b03c310, processor=0x45fa5995c60, scratch_pool=0x45f9b03c028) at subversion/libsvn_client/merge.c:3128 #4 0x045fa3e5150b in diff_deleted_dir (path=0x45fa2d5f0b0 "A/D/G", pb=0x45fa6f430a0, scratch_pool=0x45f9b03c028) at subversion/libsvn_client/repos_diff.c:604 #5 0x045fa3e516a2 in delete_entry (path=0x45fa2d5f0b0 "A/D/G", base_revision=5, parent_baton=0x45fa6f430a0, pool=0x45fa2d5f028) at subversion/libsvn_client/repos_diff.c:649 #6 0x045fa7b4f6ad in delete_entry (path=0x45fa2d5f0b0 "A/D/G", base_revision=5, parent_baton=0x45fa83920d8, pool=0x45fa2d5f028) at subversion/libsvn_delta/cancel.c:95 #7 0x045fa7b4f6ad in delete_entry (path=0x45fa2d5f0b0 "A/D/G", base_revision=5, parent_baton=0x45fa83920c8, pool=0x45fa2d5f028) at subversion/libsvn_delta/cancel.c:95 #8 0x045f9ef4bbbe in update_entry (b=0x45f9c002410, s_rev=2, s_path=0x45fa2d5f0a0 "/trunk/A/D/G", s_entry=0x45fa2338228, t_path=0x45fa2d5f0b8 "/trunk/A/D/G", t_entry=0x45fa2338910, dir_baton=0x45fa83920c8, e_path=0x45fa2d5f0b0 "A/D/G", info=0x0, wc_depth=svn_depth_infinity, requested_depth=svn_depth_infinity, pool=0x45fa2d5f028) at subversion/libsvn_repos/reporter.c:1007 #9 0x045f9ef4cc89 in delta_dirs (b=0x45f9c002410, s_rev=2, s_path=0x45fa83920a0 "/trunk/A/D", t_path=0x45fa83920b8 "/trunk/A/D", dir_baton=0x45fa83920c8, e_path=0x45fa83920b0 "A/D", start_empty=0, wc_depth=svn_depth_infinity, requested_depth=svn_depth_infinity, pool=0x45fa8392028) at subversion/libsvn_repos/reporter.c:1325 #10 0x045f9ef4bebf in update_entry (b=0x45f9c002410, s_rev=2, s_path=0x45fa83920a0 "/trunk/A/D", s_entry=0x45f9d624328, t_path=0x45fa83920b8 "/trunk/A/D", t_entry=0x45f9d624ba8, dir_baton=0x45fa6b9d0c8, e_path=0x45fa83920b0 "A/D", info=0x0, wc_depth=svn_depth_infinity, requested_depth=svn_depth_infinity, pool=0x45fa8392028) at subversion/libsvn_repos/reporter.c:1037 #11 0x045f9ef4cc89 in delta_dirs (b=0x45f9c002410, s_rev=2, s_path=0x45fa6b9d0a0 "/trunk/A", t_path=0x45fa6b9d0b8 "/trunk/A", dir_baton=0x45fa6b9d0c8, e_path=0x45fa6b9d0b0 "A", start_empty=0, wc_depth=svn_depth_infinity, requested_depth=svn_depth_infinity, pool=0x45fa6b9d028) at subversion/libsvn_repos/reporter.c:1325 #12 0x045f9ef4bebf in update_entry (b=0x45f9c002410, s_rev=2, s_path=0x45fa6b9d0a0 "/trunk/A", s_entry=0x45fa0645210, t_path=0x45fa6b9d0b8 "/trunk/A", t_entry=0x45fa06458f8, dir_baton=0x45f9c0030e8, e_path=0x45fa6b9d0b0 "A", info=0x0, wc_depth=svn_depth_infinity, requested_depth=svn_depth_infinity, pool=0x45fa6b9d028) at subversion/libsvn_repos/reporter.c:1037 #13 0x045f9ef4cc89 in delta_dirs (b=0x45f9c002410, s_rev=2, s_path=0x45f9c002b00 "/trunk", t_path=0x45f9c0024e8 "/trunk", dir_baton=0x45f9c0030e8, e_path=0x45f9f057447 "", start_empty=0, wc_depth=svn_depth_infinity, requested_depth=svn_depth_infinity, pool=0x45f9c002028) at subversion/libsvn_repos/reporter.c:1325 #14 0x045f9ef4d176 in drive (b=0x45f9c002410, s_rev=2, info=0x45f9c002ac8, pool=0x45f9c002028) at subversion/libsvn_repos/reporter.c:1390 #15 0x045f9ef4d5ab in finish_report (b=0x45f9c002410, pool=0x45f9c002028) at subversion/libsvn_repos/reporter.c:1454 #16 0x045f9ef4da6b in svn_repos_finish_report (baton=0x45f9c002410, pool=0x45f9c002028) at subversion/libsvn_repos/reporter.c:1551 #17 0x045fa150843b in reporter_finish_report (reporter_baton=0x45f9c002698, pool=0x45f9c002028) at subversion/libsvn_ra_local/ra_plugin.c:255 #18 0x045fa3e2c040 in drive_merge_report_editor (target_abspath=0x45fa59951a0 "/tmp/repro-lp1288829/wc/branches/dev", source=0x45f9c0020a0, children_with_mergeinfo=0x45fa6d9d478, processor=0x45fa5995c60, depth=svn_depth_infinity, merge_b=0x7
RE: Bug report: svn assert failure: svn: subversion/libsvn_client/merge.c:3128: merge_dir_deleted: Assertion `delb != ((void *)0)' failed.
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: zaterdag 15 maart 2014 09:45 > To: Danilo Piazzalunga > Cc: users@subversion.apache.org > Subject: Re: Bug report: svn assert failure: svn: > subversion/libsvn_client/merge.c:3128: merge_dir_deleted: Assertion `delb > != ((void *)0)' failed. > > On Fri, Mar 14, 2014 at 10:53:05PM +0100, Danilo Piazzalunga wrote: > > Hi all, > > I am asking for confirmation before reporting a bug > > > > Using Subversion 1.8.8 installed from Ubuntu 14.04 packages, svn > > crashed while performing a merge operation involving a replaced > > directory. > > > > I already reportted this bug to Ubuntu Launchpad as > > https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1288829 > > > > I was able to reproduce the bug with Subversion 1.9.0-dev trunk > > (r1577730) with a self-contained test case (see attachment). > > > > Can I report this to the Issue Tracker? It would be nice if the thread (that should be referred from the issue) actually discussed the issue. The only thing discussed here now is that there is some way to trigger the assertion. Not how it can be triggered, or how common the problem is. And if it is perhaps the result three steps after a user error or something... I really hope the issue will be more informative than the simple text ' svn assert failure: svn: subversion/libsvn_client/merge.c:3128: merge_dir_deleted: Assertion `delb != ((void *)0)' failed.' as our changelog would be 'very user friendly' if we would describe all issues like this. Bert
RE: Bug report: svn assert failure: svn: subversion/libsvn_client/merge.c:3128: merge_dir_deleted: Assertion `delb != ((void *)0)' failed.
> -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: zaterdag 15 maart 2014 10:03 > To: 'Stefan Sperling'; 'Danilo Piazzalunga' > Cc: users@subversion.apache.org > Subject: RE: Bug report: svn assert failure: svn: > subversion/libsvn_client/merge.c:3128: merge_dir_deleted: Assertion `delb > != ((void *)0)' failed. > > > > > -Original Message- > > From: Stefan Sperling [mailto:s...@elego.de] > > Sent: zaterdag 15 maart 2014 09:45 > > To: Danilo Piazzalunga > > Cc: users@subversion.apache.org > > Subject: Re: Bug report: svn assert failure: svn: > > subversion/libsvn_client/merge.c:3128: merge_dir_deleted: Assertion > `delb > > != ((void *)0)' failed. > > > > On Fri, Mar 14, 2014 at 10:53:05PM +0100, Danilo Piazzalunga wrote: > > > Hi all, > > > I am asking for confirmation before reporting a bug > > > > > > Using Subversion 1.8.8 installed from Ubuntu 14.04 packages, svn > > > crashed while performing a merge operation involving a replaced > > > directory. > > > > > > I already reportted this bug to Ubuntu Launchpad as > > > https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1288829 > > > > > > I was able to reproduce the bug with Subversion 1.9.0-dev trunk > > > (r1577730) with a self-contained test case (see attachment). > > > > > > Can I report this to the Issue Tracker? > > It would be nice if the thread (that should be referred from the issue) > actually discussed the issue. > > The only thing discussed here now is that there is some way to trigger the > assertion. Not how it can be triggered, or how common the problem is. > > And if it is perhaps the result three steps after a user error or > something... > > I really hope the issue will be more informative than the simple text ' svn > assert failure: svn: subversion/libsvn_client/merge.c:3128: > merge_dir_deleted: Assertion `delb != ((void *)0)' failed.' as our changelog > would be 'very user friendly' if we would describe all issues like this. The really interesting thing here is the 'svn merge --force' Without the '--force' the merge just succeeds without a problem. That would be really useful information to add to an issue... When I tried to create a reproduction recipe as part of the testsuite that was something I missed... With Subversion 1.8 I would really recommend not using this argument. Before 1.8 the merge infrastructure couldn't really test if a directory delete was exactly valid, while with 1.8 we resolved that problem. We just don't have many tests that use this '--force' and that is what triggers the segfault for you. I would assume a bugfix will be in the next patch release as this problem is most likely easy to fix. (I expect that I have a patch in the next half hour) Bert
RE: Bug report: svn assert failure: svn: subversion/libsvn_client/merge.c:3128: merge_dir_deleted: Assertion `delb != ((void *)0)' failed.
> -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: zaterdag 15 maart 2014 10:31 > To: 'Stefan Sperling'; 'Danilo Piazzalunga' > Cc: users@subversion.apache.org > Subject: RE: Bug report: svn assert failure: svn: > subversion/libsvn_client/merge.c:3128: merge_dir_deleted: Assertion `delb > != ((void *)0)' failed. > > > > > -Original Message- > > From: Bert Huijben [mailto:b...@qqmail.nl] > > Sent: zaterdag 15 maart 2014 10:03 > > To: 'Stefan Sperling'; 'Danilo Piazzalunga' > > Cc: users@subversion.apache.org > > Subject: RE: Bug report: svn assert failure: svn: > > subversion/libsvn_client/merge.c:3128: merge_dir_deleted: Assertion > `delb > > != ((void *)0)' failed. > > > > > > > > > -Original Message- > > > From: Stefan Sperling [mailto:s...@elego.de] > > > Sent: zaterdag 15 maart 2014 09:45 > > > To: Danilo Piazzalunga > > > Cc: users@subversion.apache.org > > > Subject: Re: Bug report: svn assert failure: svn: > > > subversion/libsvn_client/merge.c:3128: merge_dir_deleted: Assertion > > `delb > > > != ((void *)0)' failed. > > > > > > On Fri, Mar 14, 2014 at 10:53:05PM +0100, Danilo Piazzalunga wrote: > > > > Hi all, > > > > I am asking for confirmation before reporting a bug > > > > > > > > Using Subversion 1.8.8 installed from Ubuntu 14.04 packages, svn > > > > crashed while performing a merge operation involving a replaced > > > > directory. > > > > > > > > I already reportted this bug to Ubuntu Launchpad as > > > > > https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1288829 > > > > > > > > I was able to reproduce the bug with Subversion 1.9.0-dev trunk > > > > (r1577730) with a self-contained test case (see attachment). > > > > > > > > Can I report this to the Issue Tracker? > > > > It would be nice if the thread (that should be referred from the issue) > > actually discussed the issue. > > > > The only thing discussed here now is that there is some way to trigger the > > assertion. Not how it can be triggered, or how common the problem is. > > > > And if it is perhaps the result three steps after a user error or > > something... > > > > I really hope the issue will be more informative than the simple text ' > svn > > assert failure: svn: subversion/libsvn_client/merge.c:3128: > > merge_dir_deleted: Assertion `delb != ((void *)0)' failed.' as our > changelog > > would be 'very user friendly' if we would describe all issues like this. > > The really interesting thing here is the 'svn merge --force' > Without the '--force' the merge just succeeds without a problem. > > That would be really useful information to add to an issue... > > When I tried to create a reproduction recipe as part of the testsuite that > was something I missed... > > > With Subversion 1.8 I would really recommend not using this argument. > Before > 1.8 the merge infrastructure couldn't really test if a directory delete was > exactly valid, while with 1.8 we resolved that problem. > > We just don't have many tests that use this '--force' and that is what > triggers the segfault for you. > > I would assume a bugfix will be in the next patch release as this problem is > most likely easy to fix. (I expect that I have a patch in the next half > hour) A very minimalistic reproduction is: $ svn checkout # r1 $ svn mkdir A $ svn ci -m "" # r2 $ svn up -r1 $ svn merge --force --ignore-ancestry -c2 . . This merge will cause the segfault with --force, while the merge succeeds without problems without the --force. The problem is fixed on trunk in r1577812, but that doesn't remove my recommendation of stopping to use --force with 1.8. Before Subversion 1.8 merge without --force would sometimes raise invalid tree conflicts in similar cases, but as that problem has been resolved you typically want to know about the conflicts that --force will hide from you. Bert
Re: svnhook question
Op 15-mrt.-2014 04:08 schreef "Andreas Stieger" : > > Hello, > > On 14/03/14 17:15, Havlovick, Ron wrote: > > When the last person commits their files into svn, post svnhook I > > believe, an asci file will be created or written to, which contains the > > revision number of that last svn commit. > > Contrary to what Henrik wrote.. just ad a post-commit hook with > something like this: > > GNU/Linux: > > #!/bin/sh > REPOS="$1" > REV="$2" > echo "$REV" > /path/to/file.txt > > Windows: > > SET REPOS-PATH=%1 > SET REV=%2 > echo %REV% > C:\Path\to\file.txt > Careful: this does not guarantee that file.txt contains the last committed revision. The post-commit hook can be running concurrently for multiple commits, so there is a race here. Johan
