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

Re: Merge tracking: Getting only revision numbers in svn log

From: Mark Phippard <markphip_at_gmail.com>
Date: Fri, 22 Aug 2008 10:47:16 -0400

On Fri, Aug 22, 2008 at 10:33 AM, Julian Foad
<julianfoad_at_btopenworld.com> wrote:
> On Fri, 2008-08-22 at 13:19 +0200, Eirik Bjørsnøs wrote:
>> Hi guys,
>>
>> I'm currently working on making my version control history search
>> tool[1] merge tracking aware.
>
> Heh! I hadn't seen that before. Looks useful.

Same here. Very interesting looking tool. Is it open source?

>> 1) If the commit history has many merges and/or big merges a lot of
>> redundant log information is put on the wire. The information for a
>> commit will be logged once for the commit itself and then once more
>> for each merge of the revision.
>>
>> 2) Depending on the implementation in the Subversion server I would
>> imagine that getting all the revision information for merged revisions
>> put some extra load on the server.
>>
>> Given that I only need the revision numbers for merged revisions I
>> have the following questions:
>>
>> a) Is there a general interest in adding a switch that will make svn
>> log only return revision numbers for merged revisions? Or is this
>> somewhat of a corner case that normal users will never run into?
>
> Split the request up into two parts:
>
> a1) A user-interface option for the client "svn log" to show only
> revision numbers for the merged revisions.
>
> a2) An API option and library implementation for suppressing all the
> rest of the info from the client-server communication.
>
> These two are independent: apart from efficiency (OK, I know that is
> your motivating issue), either one can be implemented without the other
> one. I expect you only need (a2).
>
> At what level are you interfacing with the Subversion libraries? JavaHL?

We've discussed some general API improvements in the past.

1) It would be desirable if a "normal" svn log included a boolean that
indicated if a given revision was a merge. That could then allow a
caller to do a follow-up call to get the details for that revision.

2) It would be nice to have some kind of control over the depth of
recursion. I think this could be a simple as a boolean that either
goes only 1-level deep or infinite. I think you are going to
typically want one or the other.

These changes would be useful to GUI tools and also tools that have
their own cache. They'd also let these tools not hit the repos so
hard and generally provide better performance.

-- 
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-08-22 16:47:31 CEST

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.