On Wed, 2008-10-22 at 00:42 +0530, Kamesh Jayachandran wrote:
>
> Thanks for the explanation Paul, Casted my vote.
That's great. I wasn't understanding it well enough to cast a +1 when I
finished my afternoon a few hours ago, so I cast a +0. I'm glad that you
did.
- Julian
> With regards
> Kamesh Jayachandran
>
> -----Original Message-----
> From: Paul Burba [mailto:ptburba_at_gmail.com]
> Sent: Tue 10/21/2008 9:49 PM
> To: Kamesh Jayachandran; Julian Foad
> Cc: Subversion Development
> Subject: Question on r33693 group for 1.5.x backport
>
> On IRC today:
>
> <Kamesh> pburba: I need few clarifications regarding r33693's
> testcase?
>
> <pburba> Kamesh: what specifically?
>
> <Kamesh> Last merge in the testcase
> <Kamesh> Adds some mergeinfo to A_COPY2/C_MOVED
> <Kamesh> which I am not comfortable with
> <Kamesh> It adds SVN_PROP_MERGEINFO : '/A/C_MOVED:3-10\n' +
> <Kamesh> + '/A_COPY/C:8\n' +
> <Kamesh> + '/A_COPY/C_MOVED:8
> <Kamesh> To be precise it adds 2 mergeinfos
> <Kamesh> /A/C_MOVED:3-10 and /A_COPY/C_MOVED:8 can you explain why?
>
> <julianf> pburba/Kamesh: I hadn't noticed that but I am listening with
> interest.
>
> <pburba> Kamesh: One moment...
>
> <Kamesh> ok
>
> <pburba> Kamesh / julianf: '/A/C_MOVED:3-10' is added to describe the
> merge of all available revisions from 'A' to 'A_COPY_2', which is
> r3-10. The fact that this mergeinfo describes some non-existent paths
> is a long standing problem due to the fact that a path can inherit
> ranges from it's parent where the path doesn't exist - see
> http://subversion.tigris.org/issues/show_bug.cgi?id=3157#desc8 "B2)
> Worse that the explicit mergeinfo...".
>
> <pburba> Kamesh / julianf: Re '/A_COPY/C_MOVED:8': still looking...
>
> <Kamesh> Paul: I am leaving now, can you post your finding to my email
> <pburba> Kamesh: Will do
> <Kamesh> I will catch up in next 2 hours once I reach home,
> <Kamesh> thanks
>
> Kamesh - Here is the rest...
>
> Re '/A_COPY/C_MOVED:8' that is a result of r32975:
>
> 'Fix bug which occurs when a merge adds explicit mergeinfo to a
> subtree that
> had no explicit mergeinfo prior to the merge. This new mergeinfo
> could
> obstruct any mergeinfo the path previously inherited and the new path
> was not getting mergeinfo set that described the merge itself -- See
> http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=142460.'
>
> What happens in this case is that
> libsvn_client/merge.c:merge_props_changed() considers
> 'A_COPY_2/C_MOVED' as a subtree with added explicit mergeinfo, which
> it is, but of course the whole path is added. Later,
> merge.c:process_children_with_new_mergeinfo() figures out what
> mergeinfo 'A_COPY_2/C_MOVED' "inherits" from 'A_COPY_2',
> '/A_COPY/C_MOVED:8' in this case since 'A_COPY_2' has the explicit
> mergeinfo '/A_COPY:8', and merges this inherited mergeinfo into
> 'A_COPY_2/C_MOVED's mergienfo.
>
> I suspect we can tweak the behavior of merge_props_changed() to not
> track added paths in merge_b->paths_with_new_mergeinfo. It will
> thwart elision, but you know that I don't think much of that any more.
> Regardless, it seems both these debatable bits of mergeinfo are not
> related to the r33693 group and can be dealt with separately. If you
> agree, then the backport can be judged on its own no?
>
> Paul
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-22 01:02:33 CEST