You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Glasser <gl...@davidglasser.net> on 2007/12/24 20:01:20 UTC
issue-2987 branch: pegrev behavior for svn_fs_get_commit_and_merge_ranges
Kamesh: what is the peg/copy behavior for
svn_fs_get_commit_and_merge_ranges supposed to be (for the merge
target)?
(a) If the target is deleted and created in an unrelated way between
the beginning and end of the range, shouldn't it just return
information about the pegged version?
(b) If the target is copied from somewhere else during the range,
should it follow the copy backwards and given information about the
earlier version of the path?
I'm pretty sure (a) should be true but isn't (and since there's no
deletion in the sqlite schema, can't be until we fix that or use an
in-FS way of getting the information). Not sure what the right answer
ought to be for (b).
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: issue-2987 branch: pegrev behavior for svn_fs_get_commit_and_merge_ranges
Posted by Kamesh Jayachandran <ka...@collab.net>.
Repost: with a new test script which test the scenario better than the
earlier script.
David Glasser wrote:
> Kamesh: what is the peg/copy behavior for
> svn_fs_get_commit_and_merge_ranges supposed to be (for the merge
> target)?
>
> (a) If the target is deleted and created in an unrelated way between
> the beginning and end of the range, shouldn't it just return
> information about the pegged version?
>
Yes it should follow the right line of history.
> (b) If the target is copied from somewhere else during the range,
> should it follow the copy backwards and given information about the
> earlier version of the path?
>
Yes it should follow the right line of history.
> I'm pretty sure (a) should be true but isn't (and since there's no
> deletion in the sqlite schema, can't be until we fix that or use an
> in-FS way of getting the information).
I am not sure whether I understood you.
I use 'location segments report' to trace the right line of history.
I think deletions are marked as NULL path segments and hence no
confusion over which I don't make a call to
'get-commit-and-merge-ranges' report.
Fixed this in r28653.
I did not write a python test for this, though I have a shell script to
test. (I will write tomorrow).
I am attaching the test shell script, hope it tests the cases you marked
above.
Thanks for your interest.
With regards
Kamesh Jayachandran
Re: issue-2987 branch: pegrev behavior for svn_fs_get_commit_and_merge_ranges
Posted by Kamesh Jayachandran <ka...@collab.net>.
David Glasser wrote:
>> I am not sure whether I understood you.
>> I use 'location segments report' to trace the right line of history.
>> I think deletions are marked as NULL path segments and hence no
>> confusion over which I don't make a call to
>> 'get-commit-and-merge-ranges' report.
>>
>
> OK. So are you saying that this isn't an issue because you always
> make sure to call the get-commit-and-merge-ranges FS API with paths
> that have been previously checked to be a single location segment? In
> that case the FS API should be documented to state that the caller
> must ensure that's the case.
>
> --dave
>
>
Thanks
Fixed in r28689.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: issue-2987 branch: pegrev behavior for svn_fs_get_commit_and_merge_ranges
Posted by David Glasser <gl...@davidglasser.net>.
On Dec 27, 2007 7:13 AM, Kamesh Jayachandran <ka...@collab.net> wrote:
>
>
> David Glasser wrote:
> > Kamesh: what is the peg/copy behavior for
> > svn_fs_get_commit_and_merge_ranges supposed to be (for the merge
> > target)?
> >
> > (a) If the target is deleted and created in an unrelated way between
> > the beginning and end of the range, shouldn't it just return
> > information about the pegged version?
> >
>
> Yes it should follow the right line of history.
>
> > (b) If the target is copied from somewhere else during the range,
> > should it follow the copy backwards and given information about the
> > earlier version of the path?
> >
>
> Yes it should follow the right line of history.
> > I'm pretty sure (a) should be true but isn't (and since there's no
> > deletion in the sqlite schema, can't be until we fix that or use an
> > in-FS way of getting the information).
>
> I am not sure whether I understood you.
> I use 'location segments report' to trace the right line of history.
> I think deletions are marked as NULL path segments and hence no
> confusion over which I don't make a call to
> 'get-commit-and-merge-ranges' report.
OK. So are you saying that this isn't an issue because you always
make sure to call the get-commit-and-merge-ranges FS API with paths
that have been previously checked to be a single location segment? In
that case the FS API should be documented to state that the caller
must ensure that's the case.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: issue-2987 branch: pegrev behavior for svn_fs_get_commit_and_merge_ranges
Posted by Kamesh Jayachandran <ka...@collab.net>.
David Glasser wrote:
> Kamesh: what is the peg/copy behavior for
> svn_fs_get_commit_and_merge_ranges supposed to be (for the merge
> target)?
>
> (a) If the target is deleted and created in an unrelated way between
> the beginning and end of the range, shouldn't it just return
> information about the pegged version?
>
Yes it should follow the right line of history.
> (b) If the target is copied from somewhere else during the range,
> should it follow the copy backwards and given information about the
> earlier version of the path?
>
Yes it should follow the right line of history.
> I'm pretty sure (a) should be true but isn't (and since there's no
> deletion in the sqlite schema, can't be until we fix that or use an
> in-FS way of getting the information).
I am not sure whether I understood you.
I use 'location segments report' to trace the right line of history.
I think deletions are marked as NULL path segments and hence no
confusion over which I don't make a call to
'get-commit-and-merge-ranges' report.
Fixed this in r28653.
I did not write a python test for this, though I have a shell script to
test. (I will write tomorrow).
I am attaching the test shell script, hope it tests the cases you marked
above.
Thanks for your interest.
With regards
Kamesh Jayachandran