Re: svn commit: r25134 - in trunk/subversion: libsvn_client tests/cmdline

On 6/25/07, Paul Burba <pburba@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 <pburba@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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org