Please bear with me, I know following this isn't easy...
From the "we have more problems" department, the sample MT repository
dump on openCollabnet differs (in terms of mergeinfo) from what trunk
(r27305) would create today.
The first difference is in r14. Here is the mergeinfo for r14 from the
sample:
>svn pg svn:mergeinfo -R OpenCNSample.r14
OpenCNSample.r14\branches\b - /branches/a:4-11
/trunk:1-9
OpenCNSample.r14\branches\c - /trunk:1-4
OpenCNSample.r14\trunk - /branches/a:4-5,7
/branches/b:11-13
OpenCNSample.r14\branches\a - /trunk:1-2
But using trunk if we redo the merge of 'branches/'b to 'trunk' we end
up with differing merginfo on '/trunk':
# From a working copy for 'trunk'
>svn merge
file:///C:/SVN/src-trunk/Release/subversion/tests/cmdline/svn-test-work/
repositories/OpenCNSampleReposDump.r13/branches/b
--- Merging r11 through r13 into '.':
A products\roadmap.html
U products\index.html
U about\index.html
U index.html
U news\index.html
G .
>svn pg svn:mergeinfo -R OpenCNSample.r13
OpenCNSample.r13\branches\c - /trunk:1-4
OpenCNSample.r13\trunk - /branches/a:4-11
/branches/b:11-13
OpenCNSample.r13\branches\a - /trunk:1-2
OpenCNSample.r13\branches\b - /branches/a:4-11
/trunk:1-9
This difference is ok though as it is sematically equivalent to the
mergeinfo from the sample.
If we continue recreating the sample repository from here we end up with
this mergeinfo at r16:
OpenCNSample.r13\branches\c - /branches/a:4-11
/branches/b:11-13
/trunk:1-14
OpenCNSample.r13\trunk - /branches/a:4-11
/branches/b:11-13
OpenCNSample.r13\branches\a - /trunk:1-2
OpenCNSample.r13\branches\b - /branches/a:4-11
/trunk:1-9
Recreating r17 we see that the notifications are incorrect, only r16
update of 'jobs\index.html should be present (this is the same problem I
described in libsvn_wc/merge.c:svn_wc__merge_internal() previously in
this thread).
# From working of trunk:
>svn merge file:///C:/SVN/src-trunk/Release/subversion
/tests/cmdline/svn-test-work/repositories/OpenCNSampleReposDump.r13/bran
ches/c
--- Merging r6 through r16 into '.':
A products\medium.html
A products\roadmap.html
U products\index.html
U about\index.html
U index.html
U news\index.html
U jobs\index.html
G .
And finally we have this mergeinfo after r17 is committed:
>svn pg svn:mergeinfo -R OpenCNSample.r13
OpenCNSample.r13\branches\c - /branches/a:4-11
/branches/b:11-13
/trunk:1-14
OpenCNSample.r13\trunk - /branches/a:4-11
/branches/b:11-13
/branches/c:6-16
/trunk:5-14
^^^
TRUNK HAS MERGEINFO FROM ITSELF???
OpenCNSample.r13\branches\a - /trunk:1-2
OpenCNSample.r13\branches\b - /branches/a:4-11
/trunk:1-9
Now here is a real problem. Has anyone else already seen this and/or
have any more insight into what is going on?
Paul
P.S. Ironically, the example that started this thread, merging all
available revision ranges from 'URL/branches/a' into 'trunk' is now
(correctly) a no-op:
>svn merge file:///C:/SVN/src-trunk/Release/subversion
/tests/cmdline/svn-test-work/repositories/OpenCNSampleReposDump.r13/bran
ches/a
> -----Original Message-----
> From: Paul Burba [mailto:pburba@collab.net]
> Sent: Friday, October 19, 2007 11:30 AM
> To: Mark Phippard; Subversion Developers
> Cc: Kamesh Jayachandran
> Subject: RE: Incorrect/confusing merge notification
>
> > -----Original Message-----
> > From: Mark Phippard [mailto:markphip@gmail.com]
> > Sent: Friday, October 19, 2007 10:21 AM
> > To: Subversion Developers
> > Cc: Kamesh Jayachandran
> > Subject: Incorrect/confusing merge notification
> >
> > I saw someone else mention this in another email thread. I just
> > wanted to revive it and give a sample.
> >
> > Using the merge tracking sample repository from CollabNet:
> >
> > $ svn co $R/trunk notify
> > A notify/products
> > A notify/products/little.html
> > A notify/products/medium.html
> > A notify/products/big.html
> > A notify/products/roadmap.html
> > A notify/products/index.html
> > A notify/about
> > A notify/about/index.html
> > A notify/index.html
> > A notify/news
> > A notify/news/index.html
> > A notify/support
> > A notify/support/index.html
> > A notify/jobs
> > A notify/jobs/index.html
> > U notify
> > Checked out revision 17.
> > $ cd notify/
> > $ svn merge $R/branches/a
> > --- Merging r8 through r17 into '.':
> > A products/roadmap.html
> > $ svn st
> > M .
> >
> > The 'A'dd notification should not be happening. The file
> has already
> > been added and committed via a previous merge. All of the changes
> > from branches/a have already been merged to trunk via /branches/b.
>
> Mark,
>
> On Windows I get even more bad behavior:
>
> >svn merge %URLMT%/branches/a -c11
> --- Merging r11 into '.':
> A products\roadmap.html
> U products\index.html
> U index.html
> U news\index.html
>
> The three 'U'pdates look like a longstanding bug that is only
> seeing the light of day now that we avoid repeated merges.
> The problem is in
> libsvn_wc/merge.c:svn_wc__merge_internal():
>
> 615 else
> 616 {
> 617 svn_boolean_t same;
> 618 SVN_ERR(svn_io_files_contents_same_p(&same,
> result_target,
> 619
> merge_target, pool));
> 620
> 621 *merge_outcome = same ? svn_wc_merge_unchanged :
> svn_wc_merge_merged;
> 622 }
>
> result_target: "products/.svn/tmp/tempfile.6.tmp"
> merge_target: "products/index.html"
>
> "products/index.html" and "products/.svn/tmp/tempfile.6.tmp"
> effectively have the same contents so the merge_outcome
> should be svn_wc_merge_unchanged. I say "effectively"
> because "products/index.html" has svn:eol-style : native set
> on it, so on Windows svn_io_files_contents_same_p() thinks
> they differ, so the merge_outcome get's set to
> svn_wc_merge_merged leading to the bogus notification.
>
> The 'A products\roadmap.html' notification suffers from the same
> problem but also from an analogous problem with a prop
> add...still tracking that down.
>
> Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 22 19:18:06 2007