[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r34039 - branches/issue-2897-take2

From: Mark Phippard <markphip_at_gmail.com>
Date: Tue, 4 Nov 2008 09:58:56 -0500

On Tue, Nov 4, 2008 at 9:49 AM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> kameshj_at_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_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-04 15:59:10 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.