You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Prabhu Gnana Sundar <pr...@collab.net> on 2011/07/14 17:35:14 UTC
(Possible) bug in the way we track the mergeinfo property
Hi all,
I am in the process of writing a script which would check for the
mergeinfo of a path and see if the path is present through all the
revisions mentioned in the mergeinfo property. If the path was not found
for any revision range then the script would suggest(as of now) a better
way to propget the mergeinfo property or even propset the correct
mergeinfo property (not yet decided on this though).
In the process of testing the script against our "trunk" source I could
see some bogus mergeinfo properties when there is a break in the history.
Here is an example:
The mergeinfo for
http://svn.apache.org/repos/asf/subversion/branches/tree-conflicts is
868291-873154
but if I do location_segments for this range of revision for the above
path, I get
r868291 - r872329: subversion/branches/tree-conflicts
r872330 - r872524: null
r872525 - r873154: subversion/branches/tree-conflicts
After looking at log -v, it was clear that the
"subversion/branches/tree-conflicts" was deleted and copied (i.e replaced).
Logically the branch "tree-conflicts" was not present at all at the
revision range r872330-872524.
This brings a breakage of history. But the mergeinfo is not clear enough
to show this change.
I tested the same case with the 1.6.12, 1.6.17 and the trunk builds. The
(possible) bug is seen in all the three cases.
I have not yet filed any bug so far. Please share your thoughts.
--
Prabhu
Re: (Possible) bug in the way we track the mergeinfo property
Posted by Paul Burba <pt...@gmail.com>.
On Fri, Jul 15, 2011 at 5:24 AM, Prabhu Gnana Sundar
<pr...@collab.net> wrote:
> On Thursday 14 July 2011 09:18 PM, Paul Burba wrote:
>>
>> On Thu, Jul 14, 2011 at 11:35 AM, Prabhu Gnana Sundar
>> <pr...@collab.net> wrote:
>>>
>>> Hi all,
>>>
>>> I am in the process of writing a script which would check for the
>>> mergeinfo
>>> of a path and see if the path is present through all the revisions
>>> mentioned
>>> in the mergeinfo property. If the path was not found for any revision
>>> range
>>> then the script would suggest(as of now) a better way to propget the
>>> mergeinfo property or even propset the correct mergeinfo property (not
>>> yet
>>> decided on this though).
>>>
>>> In the process of testing the script against our "trunk" source I could
>>> see
>>> some bogus mergeinfo properties when there is a break in the history.
>>>
>>> Here is an example:
>>>
>>> The mergeinfo for
>>> http://svn.apache.org/repos/asf/subversion/branches/tree-conflicts is
>>> 868291-873154
>>> but if I do location_segments for this range of revision for the above
>>> path,
>>> I get
>>> r868291 - r872329: subversion/branches/tree-conflicts
>>> r872330 - r872524: null
>>> r872525 - r873154: subversion/branches/tree-conflicts
>>>
>>> After looking at log -v, it was clear that the
>>> "subversion/branches/tree-conflicts" was deleted and copied (i.e
>>> replaced).
>>> Logically the branch "tree-conflicts" was not present at all at the
>>> revision
>>> range r872330-872524.
>>> This brings a breakage of history. But the mergeinfo is not clear enough
>>> to
>>> show this change.
>>>
>>> I tested the same case with the 1.6.12, 1.6.17 and the trunk builds. The
>>> (possible) bug is seen in all the three cases.
>>>
>>> I have not yet filed any bug so far. Please share your thoughts.
>>
>> Hi Prabhu,
>>
>> There are a few known issues where mergeinfo can be created which
>> describes non-existent merge sources:
>>
>> One still open:
>>
>> http://subversion.tigris.org/issues/show_bug.cgi?id=3867
>>
>> Two which have been fixed:
>>
>> http://subversion.tigris.org/issues/show_bug.cgi?id=3432
>> http://subversion.tigris.org/issues/show_bug.cgi?id=3669
>>
>> I might be forgetting a couple others, but those are the ones that come to
>> mind.
>>
>> You might want to check if one of those three is the culprit here.
>
> Thanks Paul, this case is different from all the above three cases though it
> looked
> quite similar to the case,
> http://subversion.tigris.org/issues/show_bug.cgi?id=3669
>
> Here there seems to be no sign of inheritance of mergeinfo as is the case in
> "3669" and no sign of
> copyfrom as is the case in "3432".
Hi Prabhu,
I added issue #3961 to track this and added a test in r1147299.
Paul
>
>
> Regards,
> Prabhu
>
>
Re: (Possible) bug in the way we track the mergeinfo property
Posted by Prabhu Gnana Sundar <pr...@collab.net>.
On Thursday 14 July 2011 09:18 PM, Paul Burba wrote:
> On Thu, Jul 14, 2011 at 11:35 AM, Prabhu Gnana Sundar
> <pr...@collab.net> wrote:
>> Hi all,
>>
>> I am in the process of writing a script which would check for the mergeinfo
>> of a path and see if the path is present through all the revisions mentioned
>> in the mergeinfo property. If the path was not found for any revision range
>> then the script would suggest(as of now) a better way to propget the
>> mergeinfo property or even propset the correct mergeinfo property (not yet
>> decided on this though).
>>
>> In the process of testing the script against our "trunk" source I could see
>> some bogus mergeinfo properties when there is a break in the history.
>>
>> Here is an example:
>>
>> The mergeinfo for
>> http://svn.apache.org/repos/asf/subversion/branches/tree-conflicts is
>> 868291-873154
>> but if I do location_segments for this range of revision for the above path,
>> I get
>> r868291 - r872329: subversion/branches/tree-conflicts
>> r872330 - r872524: null
>> r872525 - r873154: subversion/branches/tree-conflicts
>>
>> After looking at log -v, it was clear that the
>> "subversion/branches/tree-conflicts" was deleted and copied (i.e replaced).
>> Logically the branch "tree-conflicts" was not present at all at the revision
>> range r872330-872524.
>> This brings a breakage of history. But the mergeinfo is not clear enough to
>> show this change.
>>
>> I tested the same case with the 1.6.12, 1.6.17 and the trunk builds. The
>> (possible) bug is seen in all the three cases.
>>
>> I have not yet filed any bug so far. Please share your thoughts.
> Hi Prabhu,
>
> There are a few known issues where mergeinfo can be created which
> describes non-existent merge sources:
>
> One still open:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3867
>
> Two which have been fixed:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3432
> http://subversion.tigris.org/issues/show_bug.cgi?id=3669
>
> I might be forgetting a couple others, but those are the ones that come to mind.
>
> You might want to check if one of those three is the culprit here.
Thanks Paul, this case is different from all the above three cases though it looked
quite similar to the case, http://subversion.tigris.org/issues/show_bug.cgi?id=3669
Here there seems to be no sign of inheritance of mergeinfo as is the case in "3669" and no sign of
copyfrom as is the case in "3432".
Regards,
Prabhu
RE: (Possible) bug in the way we track the mergeinfo property
Posted by Kamesh Jayachandran <ka...@collab.net>.
It has to do with the 'merge --reintegrate'.
IIUC reintegrate merge just records the svn:mergeinfo after the "url to url merge" without bothering about *full single line of continuous history a.k.a single location segment* of merge source. I mean reintegrate merge should record the mergeinfo as per the outcome of location segments report.
With regards
Kamesh Jayachandran
-----Original Message-----
From: Paul Burba [mailto:ptburba@gmail.com]
Sent: Thu 7/14/2011 9:18 PM
To: Prabhu Gnana Sundar Ponnarasu
Cc: dev@subversion.apache.org
Subject: Re: (Possible) bug in the way we track the mergeinfo property
On Thu, Jul 14, 2011 at 11:35 AM, Prabhu Gnana Sundar
<pr...@collab.net> wrote:
> Hi all,
>
> I am in the process of writing a script which would check for the mergeinfo
> of a path and see if the path is present through all the revisions mentioned
> in the mergeinfo property. If the path was not found for any revision range
> then the script would suggest(as of now) a better way to propget the
> mergeinfo property or even propset the correct mergeinfo property (not yet
> decided on this though).
>
> In the process of testing the script against our "trunk" source I could see
> some bogus mergeinfo properties when there is a break in the history.
>
> Here is an example:
>
> The mergeinfo for
> http://svn.apache.org/repos/asf/subversion/branches/tree-conflicts is
> 868291-873154
> but if I do location_segments for this range of revision for the above path,
> I get
> r868291 - r872329: subversion/branches/tree-conflicts
> r872330 - r872524: null
> r872525 - r873154: subversion/branches/tree-conflicts
>
> After looking at log -v, it was clear that the
> "subversion/branches/tree-conflicts" was deleted and copied (i.e replaced).
> Logically the branch "tree-conflicts" was not present at all at the revision
> range r872330-872524.
> This brings a breakage of history. But the mergeinfo is not clear enough to
> show this change.
>
> I tested the same case with the 1.6.12, 1.6.17 and the trunk builds. The
> (possible) bug is seen in all the three cases.
>
> I have not yet filed any bug so far. Please share your thoughts.
Hi Prabhu,
There are a few known issues where mergeinfo can be created which
describes non-existent merge sources:
One still open:
http://subversion.tigris.org/issues/show_bug.cgi?id=3867
Two which have been fixed:
http://subversion.tigris.org/issues/show_bug.cgi?id=3432
http://subversion.tigris.org/issues/show_bug.cgi?id=3669
I might be forgetting a couple others, but those are the ones that come to mind.
You might want to check if one of those three is the culprit here.
Paul
Re: (Possible) bug in the way we track the mergeinfo property
Posted by Paul Burba <pt...@gmail.com>.
On Thu, Jul 14, 2011 at 11:35 AM, Prabhu Gnana Sundar
<pr...@collab.net> wrote:
> Hi all,
>
> I am in the process of writing a script which would check for the mergeinfo
> of a path and see if the path is present through all the revisions mentioned
> in the mergeinfo property. If the path was not found for any revision range
> then the script would suggest(as of now) a better way to propget the
> mergeinfo property or even propset the correct mergeinfo property (not yet
> decided on this though).
>
> In the process of testing the script against our "trunk" source I could see
> some bogus mergeinfo properties when there is a break in the history.
>
> Here is an example:
>
> The mergeinfo for
> http://svn.apache.org/repos/asf/subversion/branches/tree-conflicts is
> 868291-873154
> but if I do location_segments for this range of revision for the above path,
> I get
> r868291 - r872329: subversion/branches/tree-conflicts
> r872330 - r872524: null
> r872525 - r873154: subversion/branches/tree-conflicts
>
> After looking at log -v, it was clear that the
> "subversion/branches/tree-conflicts" was deleted and copied (i.e replaced).
> Logically the branch "tree-conflicts" was not present at all at the revision
> range r872330-872524.
> This brings a breakage of history. But the mergeinfo is not clear enough to
> show this change.
>
> I tested the same case with the 1.6.12, 1.6.17 and the trunk builds. The
> (possible) bug is seen in all the three cases.
>
> I have not yet filed any bug so far. Please share your thoughts.
Hi Prabhu,
There are a few known issues where mergeinfo can be created which
describes non-existent merge sources:
One still open:
http://subversion.tigris.org/issues/show_bug.cgi?id=3867
Two which have been fixed:
http://subversion.tigris.org/issues/show_bug.cgi?id=3432
http://subversion.tigris.org/issues/show_bug.cgi?id=3669
I might be forgetting a couple others, but those are the ones that come to mind.
You might want to check if one of those three is the culprit here.
Paul