You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pt...@gmail.com> on 2008/10/21 16:19:48 UTC
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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Question on r33693 group for 1.5.x backport
Posted by Julian Foad <ju...@btopenworld.com>.
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@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Question on r33693 group for 1.5.x backport
Posted by Kamesh Jayachandran <ka...@collab.net>.
Thanks for the explanation Paul, Casted my vote.
With regards
Kamesh Jayachandran
-----Original Message-----
From: Paul Burba [mailto:ptburba@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