You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Alexander Kitaev <Al...@svnkit.com> on 2008/08/27 17:47:01 UTC
1.5.1(x) regression bug with mergeinfo
Hello,
Please find reproduction script for the bug attached. It does work with
Subversion 1.5.0 (displays merge history) and doesn't work with
Subversion 1.5.1 and 1.5.x (r32765).
--
Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
Re: 1.5.1(x) regression bug with mergeinfo
Posted by "C. Michael Pilato" <cm...@collab.net>.
Alexander Kitaev wrote:
> Hello,
>
> Please find reproduction script for the bug attached. It does work with
> Subversion 1.5.0 (displays merge history) and doesn't work with
> Subversion 1.5.1 and 1.5.x (r32765).
I can see in the debugger that my mergeinfo differencing logic *is* getting
the right information. Seems some other handling code is dropping the ball
here. Still looking into it.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.5.1(x) regression bug with mergeinfo
Posted by "C. Michael Pilato" <cm...@collab.net>.
C. Michael Pilato wrote:
> Alexander Kitaev wrote:
>> Hello,
>>
>> Please find reproduction script for the bug attached. It does work with
>> Subversion 1.5.0 (displays merge history) and doesn't work with
>> Subversion 1.5.1 and 1.5.x (r32765).
>
> I think there are a two of problems here. First, this merge:
>
> ${SVN} merge -r3:4 ${URL}/branches/branch/file.txt trunk-wc/file_copy.txt
>
> seems to produce mergeinfo like so:
>
> /branches/branch/file.txt:4
> /branches/branch/file_copy.txt:4
>
> Why? The source of the merge was file.txt -- why does file_copy.txt get a
> listing here?
>
> Secondly, this bogus file_copy.txt mergeinfo source causes the nested call
> to do_logs() during 'svn log -g' to raise an FS_NOT_FOUND error. That's by
> design. But what might *not* be by design is that this error -- raised due
> to problems with exactly one path out of several -- is preventing the
> handling of the rest of the paths.
>
> I'll open an issue or two for this. Thanks, Alexander.
Filed issues 3270 and 3271.
http://subversion.tigris.org/issues/show_bug.cgi?id=3270
http://subversion.tigris.org/issues/show_bug.cgi?id=3271
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.5.1(x) regression bug with mergeinfo
Posted by "C. Michael Pilato" <cm...@collab.net>.
Alexander Kitaev wrote:
> Hello,
>
> Please find reproduction script for the bug attached. It does work with
> Subversion 1.5.0 (displays merge history) and doesn't work with
> Subversion 1.5.1 and 1.5.x (r32765).
I think there are a two of problems here. First, this merge:
${SVN} merge -r3:4 ${URL}/branches/branch/file.txt trunk-wc/file_copy.txt
seems to produce mergeinfo like so:
/branches/branch/file.txt:4
/branches/branch/file_copy.txt:4
Why? The source of the merge was file.txt -- why does file_copy.txt get a
listing here?
Secondly, this bogus file_copy.txt mergeinfo source causes the nested call
to do_logs() during 'svn log -g' to raise an FS_NOT_FOUND error. That's by
design. But what might *not* be by design is that this error -- raised due
to problems with exactly one path out of several -- is preventing the
handling of the rest of the paths.
I'll open an issue or two for this. Thanks, Alexander.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand