You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Joe Swatosh <jo...@gmail.com> on 2007/06/25 16:08:32 UTC
Re: svn commit: r25134 - in trunk/subversion: libsvn_client tests/cmdline
Hi Paul,
On 5/24/07, pburba@tigris.org <pb...@tigris.org> wrote:
> Author: pburba
> Date: Thu May 24 09:21:18 2007
> New Revision: 25134
>
> Log:
> Enable merge info inheritance from nearest ancestor path in the repository.
>
>
Hi Paul,
Sorry for the late follow up, but here goes:
Here is a test in the Ruby bindings that is failing since this commit (there
is another failure that is very similar)(I hope the Ruby is clear enough to
follow):
============
def test_merge
log = "sample log"
file = "sample.txt"
src = "sample\n"
trunk = File.join(@wc_path, "trunk")
branch = File.join(@wc_path, "branch")
trunk_path = File.join(trunk, file)
branch_path = File.join(branch, file)
ctx = make_context(log)
ctx.mkdir(trunk, branch)
File.open(trunk_path, "w") {}
File.open(branch_path, "w") {}
ctx.add(trunk_path)
ctx.add(branch_path)
rev1 = ctx.commit(@wc_path).revision
File.open(branch_path, "w") {|f| f.print(src)}
rev2 = ctx.commit(@wc_path).revision
assert_nil(ctx.merge_info(trunk))
ctx.merge(branch, rev1, branch, rev2, trunk)
merge_info = ctx.merge_info(trunk)
assert_equal(["/branch"], merge_info.keys)
assert_equal([[2, 2]], merge_info["/branch"].collect {|range| range.to_a})
rev3 = ctx.commit(@wc_path).revision
assert_equal(normalize_line_break(src), ctx.cat(trunk_path, rev3))
ctx.rm(branch_path)
rev4 = ctx.commit(@wc_path).revision
ctx.merge(branch, rev3, branch, rev4, trunk)
assert(!File.exist?(trunk_path))
merge_info = ctx.merge_info(trunk, rev4)
assert_equal(["/branch"], merge_info.keys)
assert_equal([[2, 2], [4, 4]],
merge_info["/branch"].collect {|range| range.to_a })
ctx.propdel("svn:mergeinfo", trunk)
merge_info = ctx.merge_info(trunk)
assert_equal(["/branch"], merge_info.keys)
assert_equal([[2, 2]], merge_info["/branch"].collect {|range| range.to_a})
ctx.revert(trunk_path)
File.open(trunk_path, "a") {|f| f.print(src)}
ctx.merge(branch, rev3, branch, rev4, trunk)
assert(File.exist?(trunk_path))
rev5 = ctx.commit(@wc_path).revision
File.open(trunk_path, "a") {|f| f.print(src)}
ctx.merge(branch, rev3, branch, rev4, trunk, true, false, true, true)
assert(File.exist?(trunk_path))
ctx.merge(branch, rev3, branch, rev4, trunk, true, false, true)
rev6 = ctx.commit(@wc_path).revision
assert(!File.exist?(trunk_path))
end
============
The test fails on the
rev6 = ctx.commit(@wc_path).revision
line with the following
============
1) Error:
test_merge(SvnClientTest):
Svn::Error::FsTxnOutOfDate:
D:\SVN\src-trunk\subversion\libsvn_client\commit.c:871 Commit failed
(details follow):
Out of date: '/trunk' in transaction '5-1'
D:/SVN/src-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:in
`svn_client_commit4'
D:/SVN/src-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:in `commit4'
D:/SVN/src-trunk/subversion/bindings/swig/ruby/svn/client.rb:122:in `commit'
D:/SVN/src-trunk/subversion/bindings/swig/ruby/test\test_client.rb:875:in
`test_merge'
============
This test passed until r25068 when svn_client_get_mergeinfo started
returning NULL, I patched for that and the tests passed again until
r25134.
So, is this an incorrect test, or should this test be reproduced in
the C or Python
testcases?
--
Joe Swatosh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r25134 - in trunk/subversion: libsvn_client tests/cmdline
Posted by Joe Swatosh <jo...@gmail.com>.
Hi Paul,
On 7/2/07, Paul Burba <pb...@collab.net> wrote:
> >
>
>
> Thanks for the script, that makes things clearer. But I need to point
> out that the failure you described in the Ruby test, specifically the
> "Out of date" error...
>
> > ============
> > The test fails on the
> > rev6 = ctx.commit(@wc_path).revision
> > line with the following
> > ============
> > 1) Error:
> > test_merge(SvnClientTest):
> > Svn::Error::FsTxnOutOfDate:
> > D:\SVN\src-trunk\subversion\libsvn_client\commit.c:871 Commit failed
> (details follow):
> > Out of date: '/trunk' in transaction '5-1'
> > D:/SVN/src-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:in
> > `svn_client_commit4'
> > D:/SVN/src-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:in
> `commit4'
> >
> D:/SVN/src-trunk/subversion/bindings/swig/ruby/svn/client.rb:122:in
> `commit'
> >
> D:/SVN/src-trunk/subversion/bindings/swig/ruby/test\test_client.rb:875:i
> n
> > `test_merge'
> > ============
>
> ...Is not the same "error" produced by the script. Not surprising,
> since the script and the Ruby test differ somewhat:
>
> ...
> ctx.propdel("svn:mergeinfo", trunk) <-- The script doesn't do anything
> like this
> ...
Duh. I skipped that because I misread the revert further down in the test as
reverting the whole directory.
>
>
> So the merge results in local modifications on 'wc\trunk\sample.txt' and
> 'wc\trunk', but you only revert 'wc\trunk\sample.txt'. So there is
> still a local mod lurking after the revert:
>
> C:\SVN\WC\JS_REPRODUCTION_TRUNK>svn st wc
> M wc\trunk
>
>
> Now as long as 'wc\trunk' has the svn:mergeinfo '/branch:2,4', you can
> try any way you like to merge -c4 into trunk, but it's always a no-op
> (at least for r4) so this is the correct behavior. Does that make
> sense?
>
Yes. At long last you've got though to me.
>
> Does this make sense or make things worse?
>
> Paul
>
Much better. Now I just have to decide what to do about the tests.
--
Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn commit: r25134 - in trunk/subversion: libsvn_client tests/cmdline
Posted by Paul Burba <pb...@collab.net>.
> -----Original Message-----
> From: Joe Swatosh [mailto:joe.swatosh@gmail.com]
> Sent: Sunday, July 01, 2007 3:34 PM
> To: Paul Burba
> Cc: dev@subversion.tigris.org
> Subject: Re: svn commit: r25134 - in trunk/subversion:
> libsvn_client tests/cmdline
>
<snip>
> Hi Paul,
>
> Sorry for the late reply again. While trying to understand
> this problem better I wrote a little cmd file to try to
> reproduce it. I was too lazy to rebuild r25133 so I ran it
> against my 1.4.2 installed SVN. It worked as I expected
> (deleting the file after the 6th commit. When I ran it
> against a fairly recent trunk (r25599) it "failed" as I
> expected leaving the file after the 6th commit.
Hi Joe,
Thanks for the script, that makes things clearer. But I need to point
out that the failure you described in the Ruby test, specifically the
"Out of date" error...
> ============
> The test fails on the
> rev6 = ctx.commit(@wc_path).revision
> line with the following
> ============
> 1) Error:
> test_merge(SvnClientTest):
> Svn::Error::FsTxnOutOfDate:
> D:\SVN\src-trunk\subversion\libsvn_client\commit.c:871 Commit failed
(details follow):
> Out of date: '/trunk' in transaction '5-1'
> D:/SVN/src-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:in
> `svn_client_commit4'
> D:/SVN/src-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:in
`commit4'
>
D:/SVN/src-trunk/subversion/bindings/swig/ruby/svn/client.rb:122:in
`commit'
>
D:/SVN/src-trunk/subversion/bindings/swig/ruby/test\test_client.rb:875:i
n
> `test_merge'
> ============
...Is not the same "error" produced by the script. Not surprising,
since the script and the Ruby test differ somewhat:
...
ctx.propdel("svn:mergeinfo", trunk) <-- The script doesn't do anything
like this
...
> The script
> and the two results files are attached. But after rereading
> your reply, I'm more confused than ever on at least two points:
>
> 1) This is an expected change in behavior between 1.4 and
> 1.5? Obviously
> there was no merge tracking in 1.4, so some change might
> be expected, but
> I find this rather surprising.
>
> 2) From your first paragraph:
> > the commit. But isn't the out-of-date "error" really what we would
> > expect? The merge of -r3:4 from branch to trunk deletes a child of
> > trunk, sample.txt, *and* modifies the svn:mergeinfo
> property on trunk
> > itself. But trunk is only at r3, so the commit should
> fail. If trunk
> since all the commits occur at the top of the working
> copy, I'm not sure
> why there would be a mixed revision.
>
> Thanks very much for helping me to understand this better.
Anyhow, just dealing with your script for now...
Recall every merge sets/updates the svn:mergeinfo property on the target
of the merge, tracking what revisions are merged into that target (hence
"merge tracking" :-) What your script encountered is actually part of
the Merge Tracking design, specifically "repeated merges", see:
file:///C:/SVN/src-trunk/www/merge-tracking/requirements.html#repeated-m
erge. Basically this means if the svn:mergeinfo on directory 'X' says
that 'revision N' was merged into it, repeated attempts to merge
'revision X' into that target are ignored.
So looking at your script:
> svn --version
>
> @if exist repo rd /q/s repo
> @if exist wc rd /q/s wc
>
> svnadmin create repo
> md wc
>
> set REPOS=file:///%~dp0repo
> set REPOS=%REPOS:\=/%
>
> svn co %REPOS% wc
> md wc\trunk
> md wc\branch
> echo sample >> wc\trunk\sample.txt
> echo sample >> wc\branch\sample.txt
> svn add wc\trunk wc\branch
> svn ci wc -m"1"
>
> echo sample >> wc\branch\sample.txt
> svn ci wc -m"2"
>
> svn merge %REPOS%/branch@1 %REPOS%/branch@2 wc\trunk
> svn ci wc -m"3"
> svn cat %REPOS%/trunk/sample.txt
>
> svn rm wc/branch/sample.txt
> svn ci wc -m"4"
>
> svn merge %REPOS%/branch@3 %REPOS%/branch@4 wc\trunk
>
> @if exist wc\trunk\sample.txt echo ***** file should be gone
The merge above deletes 'wc\trunk\sample.txt' but *also* sets
svn:mergeinfo for r4 on the target of the merge, i.e. wc\trunk:
C:\SVN\WC\JS_REPRODUCTION_TRUNK>svn st wc
M wc\trunk <-- svn:mergeinfo updated for r4!
D wc\trunk\sample.txt
C:\SVN\WC\JS_REPRODUCTION_TRUNK>svn pl -vR wc
Properties on 'wc\trunk':
svn:mergeinfo : /branch:2,4
C:\SVN\WC\JS_REPRODUCTION_TRUNK>svn diff wc
Property changes on: wc\trunk
___________________________________________________________________
Name: svn:mergeinfo
Merged /branch:r4
Index: wc/trunk/sample.txt
===================================================================
--- wc/trunk/sample.txt (revision 0)
+++ wc/trunk/sample.txt (working copy)
@@ -1,2 +0,0 @@
-sample
-sample
> svn revert wc\trunk\sample.txt
So the merge results in local modifications on 'wc\trunk\sample.txt' and
'wc\trunk', but you only revert 'wc\trunk\sample.txt'. So there is
still a local mod lurking after the revert:
C:\SVN\WC\JS_REPRODUCTION_TRUNK>svn st wc
M wc\trunk
> echo sample >> wc\trunk\sample.txt
> svn merge %REPOS%/branch@3 %REPOS%/branch@4 wc\trunk
> @if not exist wc\trunk\sample.txt echo ***** file with mods should
stay
This merge is actually a no-op, because 'wc\trunk' still has the
svn:mergeinfo '/branch:2,4', so the repeat merge is not attempted. Of
course from the command line output this looks no different from the
1.4.2 behavior.
> svn ci wc -m"5"
>
> echo sample >> wc\trunk\sample.txt
> svn merge --force --dry-run %REPOS%/branch@3 %REPOS%/branch@4 wc\trunk
> @if not exist wc\trunk\sample.txt echo ***** file should stay
> svn merge --force %REPOS%/branch@3 %REPOS%/branch@4 wc\trunk
> svn ci wc -m"6"
> @if exist wc\trunk\sample.txt echo ***** file should be gone
Now as long as 'wc\trunk' has the svn:mergeinfo '/branch:2,4', you can
try any way you like to merge -c4 into trunk, but it's always a no-op
(at least for r4) so this is the correct behavior. Does that make
sense?
Now if instead of reverting just 'wc\trunk\sample.txt', you reverted the
whole working copy (this is analogous to what the Ruby test did with
"ctx.propdel("svn:mergeinfo", trunk)",
C:\SVN\WC\JS_REPRODUCTION_TRUNK>svn revert -R wc
Reverted 'wc\trunk'
Reverted 'wc\trunk\sample.txt'
then the working copy would be back at r3.
C:\SVN\WC\JS_REPRODUCTION_TRUNK>svn st -uv wc
1 1 pburba wc\branch
3 3 pburba wc\trunk\sample.txt
3 3 pburba wc\trunk
0 0 ? wc
Status against revision: 4
And if we continued with your script we see the out of date error.
C:\SVN\WC\JS_REPRODUCTION_TRUNK>echo sample >> wc\trunk\sample.txt
C:\SVN\WC\JS_REPRODUCTION_TRUNK>svn merge %REPOS%/branch@3
%REPOS%/branch@4 wc\trunk
--- Merging r4:
Skipped 'wc\trunk\sample.txt'
C:\SVN\WC\JS_REPRODUCTION_TRUNK>svn ci wc -m"5"
Sending wc\trunk\sample.txt
Transmitting file data .
Committed revision 5.
C:\SVN\WC\JS_REPRODUCTION_TRUNK>echo sample >> wc\trunk\sample.txt
C:\SVN\WC\JS_REPRODUCTION_TRUNK>svn merge --force --dry-run
%REPOS%/branch@3 %REPOS%/branch@4 wc\trunk
--- Merging r4:
D wc\trunk\sample.txt
C:\SVN\WC\JS_REPRODUCTION_TRUNK>svn merge --force %REPOS%/branch@3
%REPOS%/branch@4 wc\trunk
--- Merging r4:
D wc\trunk\sample.txt
C:\SVN\WC\JS_REPRODUCTION_TRUNK>svn st wc
M wc\trunk <-- merge resulted in a property mod
on an out of date directory, can't
commit without an update.
D wc\trunk\sample.txt
C:\SVN\WC\JS_REPRODUCTION_TRUNK>svn ci wc -m"6"
Sending wc\trunk
..\..\..\subversion\libsvn_client\commit.c:871: (apr_err=160028)
svn: Commit failed (details follow):
..\..\..\subversion\libsvn_repos\commit.c:124: (apr_err=160028)
svn: Out of date: '/trunk' in transaction
'Collab-PBurba-02200-1183387220359375-1'
I stand by my previous explanation of this error. An update prior to
the commit fixes things as expected:
C:\SVN\WC\JS_REPRODUCTION_TRUNK>svn up wc
At revision 5.
C:\SVN\WC\JS_REPRODUCTION_TRUNK>svn ci -m"6" wc
Sending wc\trunk
Deleting wc\trunk\sample.txt
Committed revision 6.
Does this make sense or make things worse?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r25134 - in trunk/subversion: libsvn_client tests/cmdline
Posted by Joe Swatosh <jo...@gmail.com>.
On 6/25/07, Paul Burba <pb...@collab.net> wrote:
>
> > -----Original Message-----
> > From: Joe Swatosh [mailto:joe.swatosh@gmail.com]
> > Sent: Monday, June 25, 2007 12:09 PM
> > To: dev@subversion.tigris.org; pburba@tigris.org
> > Cc: svn@subversion.tigris.org
> > Subject: Re: svn commit: r25134 - in trunk/subversion:
> > libsvn_client tests/cmdline
> >
> > Hi Paul,
> >
> > On 5/24/07, pburba@tigris.org <pb...@tigris.org> wrote:
> > > Author: pburba
> > > Date: Thu May 24 09:21:18 2007
> > > New Revision: 25134
> > >
> > > Log:
> > > Enable merge info inheritance from nearest ancestor path in
> > the repository.
> > >
> >
> > >
> >
> > Hi Paul,
> >
> > Sorry for the late follow up, but here goes:
> >
> > Here is a test in the Ruby bindings that is failing since
> > this commit (there is another failure that is very similar)(I
> > hope the Ruby is clear enough to
> > follow):
> > ============
> > def test_merge
> > log = "sample log"
> > file = "sample.txt"
> > src = "sample\n"
> > trunk = File.join(@wc_path, "trunk")
> > branch = File.join(@wc_path, "branch")
> > trunk_path = File.join(trunk, file)
> > branch_path = File.join(branch, file)
> >
> > ctx = make_context(log)
> > ctx.mkdir(trunk, branch)
> > File.open(trunk_path, "w") {}
> > File.open(branch_path, "w") {}
> > ctx.add(trunk_path)
> > ctx.add(branch_path)
> > rev1 = ctx.commit(@wc_path).revision
> >
> > File.open(branch_path, "w") {|f| f.print(src)}
> > rev2 = ctx.commit(@wc_path).revision
> >
> > assert_nil(ctx.merge_info(trunk))
> > ctx.merge(branch, rev1, branch, rev2, trunk)
> > merge_info = ctx.merge_info(trunk)
> > assert_equal(["/branch"], merge_info.keys)
> > assert_equal([[2, 2]], merge_info["/branch"].collect
> > {|range| range.to_a})
> > rev3 = ctx.commit(@wc_path).revision
> >
> > assert_equal(normalize_line_break(src), ctx.cat(trunk_path, rev3))
> >
> > ctx.rm(branch_path)
> > rev4 = ctx.commit(@wc_path).revision
> >
> > ctx.merge(branch, rev3, branch, rev4, trunk)
> > assert(!File.exist?(trunk_path))
> >
> > merge_info = ctx.merge_info(trunk, rev4)
> > assert_equal(["/branch"], merge_info.keys)
> > assert_equal([[2, 2], [4, 4]],
> > merge_info["/branch"].collect {|range| range.to_a })
> > ctx.propdel("svn:mergeinfo", trunk)
> > merge_info = ctx.merge_info(trunk)
> > assert_equal(["/branch"], merge_info.keys)
> > assert_equal([[2, 2]], merge_info["/branch"].collect
> > {|range| range.to_a})
> >
> > ctx.revert(trunk_path)
> > File.open(trunk_path, "a") {|f| f.print(src)}
> > ctx.merge(branch, rev3, branch, rev4, trunk)
> > assert(File.exist?(trunk_path))
> > rev5 = ctx.commit(@wc_path).revision
> >
> > File.open(trunk_path, "a") {|f| f.print(src)}
> > ctx.merge(branch, rev3, branch, rev4, trunk, true, false,
> > true, true)
> > assert(File.exist?(trunk_path))
> >
> > ctx.merge(branch, rev3, branch, rev4, trunk, true, false, true)
> > rev6 = ctx.commit(@wc_path).revision
> >
> > assert(!File.exist?(trunk_path))
> > end
> > ============
> > The test fails on the
> > rev6 = ctx.commit(@wc_path).revision
> > line with the following
> > ============
> > 1) Error:
> > test_merge(SvnClientTest):
> > Svn::Error::FsTxnOutOfDate:
> > D:\SVN\src-trunk\subversion\libsvn_client\commit.c:871 Commit
> > failed (details follow):
> > Out of date: '/trunk' in transaction '5-1'
> > D:/SVN/src-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:in
> > `svn_client_commit4'
> >
> > D:/SVN/src-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:
> > in `commit4'
> >
> > D:/SVN/src-trunk/subversion/bindings/swig/ruby/svn/client.rb:1
> > 22:in `commit'
> >
> > D:/SVN/src-trunk/subversion/bindings/swig/ruby/test\test_clien
> > t.rb:875:in
> > `test_merge'
> > ============
> > This test passed until r25068 when svn_client_get_mergeinfo
> > started returning NULL, I patched for that and the tests
> > passed again until r25134.
> >
> > So, is this an incorrect test, or should this test be
> > reproduced in the C or Python testcases?
>
> Hi Joe,
>
> I have never been able to get the Ruby bindings to build on Win32, so I
> recreated this test using the command line and I get the same error on
> the commit. But isn't the out-of-date "error" really what we would
> expect? The merge of -r3:4 from branch to trunk deletes a child of
> trunk, sample.txt, *and* modifies the svn:mergeinfo property on trunk
> itself. But trunk is only at r3, so the commit should fail. If trunk
> is updated then the commit succeeds -- See the second limitation at
> http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.basic.in-action
> .mixedrevs.limits
>
> I'm really surprised this test has ever passed since the merge-tracking
> branch was merged into trunk months ago. I even rebuilt r25133, and
> checked to see if something truly wacky was going on and I get the same
> behavior.
>
> Of course I'm probably not telling you anything you don't know, and
> since I don't know anything about Ruby I might have completely
> misunderstood the test script! If that is the case maybe we can chat on
> #svn-dev tomorrow to get to the bottom of this(?)
>
Hi Paul,
Sorry for the late reply again. While trying to understand this problem
better I wrote a little cmd file to try to reproduce it. I was too lazy to
rebuild r25133 so I ran it against my 1.4.2 installed SVN. It worked as I
expected (deleting the file after the 6th commit. When I ran it against a
fairly recent trunk (r25599) it "failed" as I expected leaving the file after
the 6th commit. The script and the two results files are attached. But after
rereading your reply, I'm more confused than ever on at least two points:
1) This is an expected change in behavior between 1.4 and 1.5? Obviously
there was no merge tracking in 1.4, so some change might be expected, but
I find this rather surprising.
2) From your first paragraph:
> the commit. But isn't the out-of-date "error" really what we would
> expect? The merge of -r3:4 from branch to trunk deletes a child of
> trunk, sample.txt, *and* modifies the svn:mergeinfo property on trunk
> itself. But trunk is only at r3, so the commit should fail. If trunk
since all the commits occur at the top of the working copy, I'm not sure
why there would be a mixed revision.
Thanks very much for helping me to understand this better.
--
Joe
RE: svn commit: r25134 - in trunk/subversion: libsvn_client tests/cmdline
Posted by Paul Burba <pb...@collab.net>.
> -----Original Message-----
> From: Joe Swatosh [mailto:joe.swatosh@gmail.com]
> Sent: Monday, June 25, 2007 12:09 PM
> To: dev@subversion.tigris.org; pburba@tigris.org
> Cc: svn@subversion.tigris.org
> Subject: Re: svn commit: r25134 - in trunk/subversion:
> libsvn_client tests/cmdline
>
> Hi Paul,
>
> On 5/24/07, pburba@tigris.org <pb...@tigris.org> wrote:
> > Author: pburba
> > Date: Thu May 24 09:21:18 2007
> > New Revision: 25134
> >
> > Log:
> > Enable merge info inheritance from nearest ancestor path in
> the repository.
> >
>
> >
>
> Hi Paul,
>
> Sorry for the late follow up, but here goes:
>
> Here is a test in the Ruby bindings that is failing since
> this commit (there is another failure that is very similar)(I
> hope the Ruby is clear enough to
> follow):
> ============
> def test_merge
> log = "sample log"
> file = "sample.txt"
> src = "sample\n"
> trunk = File.join(@wc_path, "trunk")
> branch = File.join(@wc_path, "branch")
> trunk_path = File.join(trunk, file)
> branch_path = File.join(branch, file)
>
> ctx = make_context(log)
> ctx.mkdir(trunk, branch)
> File.open(trunk_path, "w") {}
> File.open(branch_path, "w") {}
> ctx.add(trunk_path)
> ctx.add(branch_path)
> rev1 = ctx.commit(@wc_path).revision
>
> File.open(branch_path, "w") {|f| f.print(src)}
> rev2 = ctx.commit(@wc_path).revision
>
> assert_nil(ctx.merge_info(trunk))
> ctx.merge(branch, rev1, branch, rev2, trunk)
> merge_info = ctx.merge_info(trunk)
> assert_equal(["/branch"], merge_info.keys)
> assert_equal([[2, 2]], merge_info["/branch"].collect
> {|range| range.to_a})
> rev3 = ctx.commit(@wc_path).revision
>
> assert_equal(normalize_line_break(src), ctx.cat(trunk_path, rev3))
>
> ctx.rm(branch_path)
> rev4 = ctx.commit(@wc_path).revision
>
> ctx.merge(branch, rev3, branch, rev4, trunk)
> assert(!File.exist?(trunk_path))
>
> merge_info = ctx.merge_info(trunk, rev4)
> assert_equal(["/branch"], merge_info.keys)
> assert_equal([[2, 2], [4, 4]],
> merge_info["/branch"].collect {|range| range.to_a })
> ctx.propdel("svn:mergeinfo", trunk)
> merge_info = ctx.merge_info(trunk)
> assert_equal(["/branch"], merge_info.keys)
> assert_equal([[2, 2]], merge_info["/branch"].collect
> {|range| range.to_a})
>
> ctx.revert(trunk_path)
> File.open(trunk_path, "a") {|f| f.print(src)}
> ctx.merge(branch, rev3, branch, rev4, trunk)
> assert(File.exist?(trunk_path))
> rev5 = ctx.commit(@wc_path).revision
>
> File.open(trunk_path, "a") {|f| f.print(src)}
> ctx.merge(branch, rev3, branch, rev4, trunk, true, false,
> true, true)
> assert(File.exist?(trunk_path))
>
> ctx.merge(branch, rev3, branch, rev4, trunk, true, false, true)
> rev6 = ctx.commit(@wc_path).revision
>
> assert(!File.exist?(trunk_path))
> end
> ============
> The test fails on the
> rev6 = ctx.commit(@wc_path).revision
> line with the following
> ============
> 1) Error:
> test_merge(SvnClientTest):
> Svn::Error::FsTxnOutOfDate:
> D:\SVN\src-trunk\subversion\libsvn_client\commit.c:871 Commit
> failed (details follow):
> Out of date: '/trunk' in transaction '5-1'
> D:/SVN/src-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:in
> `svn_client_commit4'
>
> D:/SVN/src-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:
> in `commit4'
>
> D:/SVN/src-trunk/subversion/bindings/swig/ruby/svn/client.rb:1
> 22:in `commit'
>
> D:/SVN/src-trunk/subversion/bindings/swig/ruby/test\test_clien
> t.rb:875:in
> `test_merge'
> ============
> This test passed until r25068 when svn_client_get_mergeinfo
> started returning NULL, I patched for that and the tests
> passed again until r25134.
>
> So, is this an incorrect test, or should this test be
> reproduced in the C or Python testcases?
Hi Joe,
I have never been able to get the Ruby bindings to build on Win32, so I
recreated this test using the command line and I get the same error on
the commit. But isn't the out-of-date "error" really what we would
expect? The merge of -r3:4 from branch to trunk deletes a child of
trunk, sample.txt, *and* modifies the svn:mergeinfo property on trunk
itself. But trunk is only at r3, so the commit should fail. If trunk
is updated then the commit succeeds -- See the second limitation at
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.basic.in-action
.mixedrevs.limits
I'm really surprised this test has ever passed since the merge-tracking
branch was merged into trunk months ago. I even rebuilt r25133, and
checked to see if something truly wacky was going on and I get the same
behavior.
Of course I'm probably not telling you anything you don't know, and
since I don't know anything about Ruby I might have completely
misunderstood the test script! If that is the case maybe we can chat on
#svn-dev tomorrow to get to the bottom of this(?)
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org