> -----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
Received on Mon Jul 2 16:51:28 2007