Thanks for the explanation Paul, Casted my vote.
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
Received on 2008-10-21 21:12:40 CEST