On Thu, Dec 4, 2008 at 2:14 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> What you suggest is completely adequate for this particular bug. But
> while looking at this I started to wonder if there was any way we
> could end up with target_merge_path->path being absolute and
> added_path relative, or vice-versa. It doesn't appear that this is
> possbile, but there's no reason not to make this completely
> bomb-proof, which I did in r34562.
Sounds good - my example case wouldn't have shown that issue.
> Agreed, in all cases there will be *some* natural history made
> explicit in the added subtree's mergeinfo. This is a known problem,
> see http://subversion.tigris.org/issues/show_bug.cgi?id=3157#desc8.
> "Problem" may be too strong a term, since natural history made
> explicit is, AFAICT, "redundant but not wrong".
>
> I emphasized "some" above because it might also be the case where we
> merge -r4:10 from 'trunk' to 'branch' and r5 adds the subtree
> 'branch/new_child'. Let's assume we have a situation similar to the
> bug you found and we set explicit mergeinfo on 'branch/new_child'
> describing the merge, that is, '/trunk/new_child:5-10'. The
> '/trunk/new_child:5' portion of this mergeinfo does describe natural
> history, but '/trunk/new_child:6-10' is legitimate. We could clean
> this up, but imagine that instead of -r5:10 we had a much larger range
> and instead of one added subtree we had scores. There would be some
> not insignificant communication with the repository necessary to
> figure out what mergeinfo is natural history and what is not...so my
> gut says that until this proves to be a more serious problem we are
> safe leaving it as is (I'm open to arguments the other way of course).
Ah, I see - we typically merge a single recent revision, so we really
are adding to the end, but the general case is a lot more complicated.
>> (Should have a reduced demonstration script soon, but since the code
>> is wrong by inspection, I figured I'd give people (especially Paul
>> Burba :-) a chance to look at the problem...)
>
> Thanks again for the detailed description and reproduction, you're
> becoming exhibit 'A' on how to submit a bug report!
Heh. In this case, I still had my debugging builds around (with a
bunch of '#define static' to make setting breakpoints easier) and a
full clone of our repository to play with - the reproduction script
was actually more work than the patch (and a lot easier to do after
finding the bug) because it's difficult to tell what parts of our
repository actually relate to the bug, up front...
> I'll nominate this for backport to 1.5.x too.
yay :-)
--
_Mark_ <eichin_at_thok.org> <eichin_at_gmail.com>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=979827
Received on 2008-12-04 22:23:18 CET