You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Hyrum K. Wright" <hy...@mail.utexas.edu> on 2008/11/04 14:49:20 UTC
Re: svn commit: r34039 - branches/issue-2897-take2
kameshj@tigris.org wrote:
> Author: kameshj
> Date: Tue Nov 4 05:46:50 2008
> New Revision: 34039
>
> Log:
> On issue-2897-take2 branch:
>
> * README.branch
> New file having the plan for this branch.
>
> Added:
> branches/issue-2897-take2/README.branch
>
> Added: branches/issue-2897-take2/README.branch
> URL: http://svn.collab.net/viewvc/svn/branches/issue-2897-take2/README.branch?pathrev=34039
> ==============================================================================
> --- /dev/null 00:00:00 1970 (empty, because file is newly added)
> +++ branches/issue-2897-take2/README.branch Tue Nov 4 05:46:50 2008 (r34039)
> @@ -0,0 +1,13 @@
> +This branch started with the motto of implementing issue-2897 branch
> +as per new state of backend storage schema.
> +
> +As of today(r34038) we have 'per commit mergeinfo_delta' implemented in bdb fs.
> +
> +In the subconf Julian has given a suggestion to compute the
> +'per commit mergeinfo_delta' using 'log -g client code' so
> +that one could try 'trunk svn merge --reintegrate' and
> +'issue-2897-take2 svn merge' compare and contrast easily.
> +
> +So I am going to implement 'svn_client__get_commit_and_merge_ranges'
> +using 'log -g' code as a proof of concept and port rest of client code
> +from issue-2897 branch.
We've had a number of requests for changes to the 'log -g' API, and while they
aren't going to happen before 1.6, I think they may be useful to keep in mind
for this work.
The biggest change, which is on my "I'll do it eventually" list, is to have the
receiver API return the fact that a merge occurred, but omit the actual merged
revisions. This would allow clients to decide if they want the merged revisions
and make repeated calls to the log API to get those merged revisions. I don't
how or if this impacts your work for issue 2897, but I thought I'd mention it.
-Hyrum
Re: svn commit: r34039 - branches/issue-2897-take2
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Nov 4, 2008 at 9:49 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> kameshj@tigris.org wrote:
>> Author: kameshj
>> Date: Tue Nov 4 05:46:50 2008
>> New Revision: 34039
>>
>> Log:
>> On issue-2897-take2 branch:
>>
>> * README.branch
>> New file having the plan for this branch.
>>
>> Added:
>> branches/issue-2897-take2/README.branch
>>
>> Added: branches/issue-2897-take2/README.branch
>> URL: http://svn.collab.net/viewvc/svn/branches/issue-2897-take2/README.branch?pathrev=34039
>> ==============================================================================
>> --- /dev/null 00:00:00 1970 (empty, because file is newly added)
>> +++ branches/issue-2897-take2/README.branch Tue Nov 4 05:46:50 2008 (r34039)
>> @@ -0,0 +1,13 @@
>> +This branch started with the motto of implementing issue-2897 branch
>> +as per new state of backend storage schema.
>> +
>> +As of today(r34038) we have 'per commit mergeinfo_delta' implemented in bdb fs.
>> +
>> +In the subconf Julian has given a suggestion to compute the
>> +'per commit mergeinfo_delta' using 'log -g client code' so
>> +that one could try 'trunk svn merge --reintegrate' and
>> +'issue-2897-take2 svn merge' compare and contrast easily.
>> +
>> +So I am going to implement 'svn_client__get_commit_and_merge_ranges'
>> +using 'log -g' code as a proof of concept and port rest of client code
>> +from issue-2897 branch.
>
> We've had a number of requests for changes to the 'log -g' API, and while they
> aren't going to happen before 1.6, I think they may be useful to keep in mind
> for this work.
>
> The biggest change, which is on my "I'll do it eventually" list, is to have the
> receiver API return the fact that a merge occurred, but omit the actual merged
> revisions. This would allow clients to decide if they want the merged revisions
> and make repeated calls to the log API to get those merged revisions. I don't
> how or if this impacts your work for issue 2897, but I thought I'd mention it.
I've been working on a revision graph feature and want to show merges.
This feature would be nice, but what would really help is if the log
API either took a boolean or some kind of "depth" option so that I
could limit the recursion. We have many revisions in our own
repository that recurse so much that it makes the API unusable.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn commit: r34039 - branches/issue-2897-take2
Posted by Kamesh Jayachandran <ka...@collab.net>.
Thanks Hyrum.
>The biggest change, which is on my "I'll do it eventually" list, is to have the
>receiver API return the fact that a merge occurred, but omit the actual merged
>revisions. This would allow clients to decide if they want the merged revisions
>and make repeated calls to the log API to get those merged revisions. I don't
>how or if this impacts your work for issue 2897, but I thought I'd mention it.
This 'log -g' effort is an interim effort to make wide spread testing easier instead of
having a full fledged issue-2897-take2 repo backend and all layer to do a testing.
With regards
Kamesh Jayachandran